[Bucardo-general] Question related to older thread

[Paul Theodoropoulos]

Thanks very much Mitchell. This indeed seems to have been the secret 
sauce. At the end of the script, after a one-time-copy was complete, I 
had the script updating back to to 'source/source', based upon the 
unidirectional replication design. The script no longer does that, and I 
have a successful bidirectional sync (albeit untested at this point).

On 8/12/13 2:36 AM, Mitchell Perilstein wrote:
> 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. 

-- 
Paul Theodoropoulos
www.anastrophe.com

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