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
[email protected]
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
_______________________________________________
Bucardo-general mailing list
[email protected]
https://mail.endcrypt.com/mailman/listinfo/bucardo-general
