Mon Apr 19 17:17:04 PDT 2010
- Previous message: [Slony1-general] recreating a cluster when the master dies
- Next message: [Slony1-general] [slony-general] alter a table that is in two sets
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Thanks Steve, Your suggestions were very helpful. I fixed the problem by running the following code snippet directly against the slave right after registering the cluster on the master database. I am guessing there was some mismatch between the two. All fixed. Thanks. #!/bin/bash /usr/lib/postgresql/8.4/bin/slonik << _EOF_ cluster name = $CLUSTER; node 1 admin conninfo = 'dbname=$DB1 host=$H1 user=$U'; node 2 admin conninfo = 'dbname=$DB2 host=$H2 user=$U'; subscribe set (id = 1, provider = 1, receiver = 2, forward = yes);" _EOF_ 2010/4/18 Steve Singer <ssinger at ca.afilias.info> > albert wrote: > >> Hi Steve, >> > > >> This is very strange, the error is saying that the big if/else >> block in remote_worker.c isn't matching the events even the event >> name as printed in the above message looks okay. >> >> >> Well, that sounds interesting... >> >> Here's part of the log messages from the slony process running against the >> slave database during step 1, that is... when replication is setup for the >> first time and data is moved across correctly. Note that the above TODO: >> messages are also printed and then replication messages are logged and data >> is moved correctly (My test inserts some random data into the master >> database, sleeps for a while, then dumps both the slave and master databases >> and they get diffed) >> > > This TODO error isn't the cause of your issue, one of the 'if' statements > should be an 'else if' but that is causing that log message but it isn't > causing a problem other than that. > > Which leads us back to why isn't your slave subscribing. > > Are there any locks open in the database (at the point that you've > resubscribed things and are waiting for stuff to replicate?) > > select pg_locks.*, pg_class.relname FROM pg_locks, pg_class where > pg_locks.relation=pg_class.oid; > > or something similar can show you that. > > Do you have any transactions that were started before you subscribed the > set that haven't committed yet? > > > > > > > -- > Steve Singer > Afilias Canada > Data Services Developer > 416-673-1142 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.slony.info/pipermail/slony1-general/attachments/20100419/770653aa/attachment.htm
- Previous message: [Slony1-general] recreating a cluster when the master dies
- Next message: [Slony1-general] [slony-general] alter a table that is in two sets
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-general mailing list