[Bucardo-general] Question related to older thread

[Mitchell Perilstein]

Paul, no one's answered this so I'll give it a try and if someone wants 
to correct me, please do.

Yes, when crisscrossing, each box should treat itself as master (source) 
and the other as a slave (target).   The theory goes as follows.  If you 
do a describe on one of your replicated tables, you should see three 
stored trigger procedures.  Any changes to the table will fire one of 
those (see bucardo.schema).  That trigger--running on the local 
box--will do a select on the remote box inquiring about those those 
rows. The local box will modify the loser's db (according to 
conflict_strategy) whether the loser be local or remote.  So you might 
say that each box pushes changes to the other, if you were only doing 
new and unique inserts at least. The bucardos are mostly ignorant of 
each other, except for one little trick that lets the triggers ignore 
when bucardo is doing a db write instead of the user, to avoid a 
ping-pong situation.

So your configs should mirror each other where hostnames are concerned.  
If any hell is breaking lose, it might be because a hostname is mixed up.

Hope this helps.


On 08/08/2013 07:13 PM, Paul Theodoropoulos wrote:
> I wasn't on the list back when the thread I'm quoting from was active, 
> so I don't believe there's any way to continue that thread. That said, 
> quoting from the thread:
>
> Mitchell Perilstein wrote:
>
>> Again, not saying it's right, but it's roughly something like this.
>> Names changed, error checks not shown, repeated for a number of tables
>> and databases, etc..
>>
>>       bucardo add database    source_xx host=tplocalvirt user=myuser
>> db=xx dbport=5432
>>       bucardo add database    --force target_xx host=mypeerhost
>> user=myuser db=xx dbport=5432
>>       bucardo add table       $ALLMYTABLES db=source_xx herd=xxherd
>>       bucardo add dbgroup     xxgroup source_xx:source target_xx:target
>>       bucardo start           --log-destination=syslog 
>> -no-exit-on-nosync
>>       bucardo add sync        xx_sync herd=xxherd
>> conflict_strategy=latest onetimecopy=1 dbs=xxgroup
>>       bucardo set syslog_facility=local6
>>       bucardo set mcp_dbproblem_sleep=0.5
>>       bucardo set isolation_level='read uncommitted'
>>       bucardo set statement_chunk_size=1000
>>       bucardo activate sync   xx_sync
>>
> I'm attempting to set up a bidirectional/criss-cross multimaster 
> setup, and I'm failing rather spectacularly.  One thing that my script 
> does is - after
> all the syncs are set up - and the one-time-copy is ostensibly 
> finished (still working on eliminating 'ostensibly') - I then modify the
> dbgroups to have both sides be 'source' - which is my understanding of 
> what makes the setup master-master.
>
> But when doing a criss-cross multimaster - do you retain the 'source 
> target' designation? So both really *are* masters, but they treat the 
> other as a slave?
> Every time I try and fire up the remote server's bucardo with 
> source/source, all hell breaks loose, and the syncs go "Bad".
>
>
>
> _______________________________________________
> Bucardo-general mailing list
> Bucardo-general at bucardo.org
> https://mail.endcrypt.com/mailman/listinfo/bucardo-general



Confidentiality Notice: This e-mail (including any attachments) is intended only for the recipients named above. It may contain confidential or privileged information and should not be read, copied or otherwise used by any other person. If you are not a named recipient, please notify the sender of that fact and delete the e-mail from your system.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.endcrypt.com/pipermail/bucardo-general/attachments/20130812/cf916a60/attachment.html>