Tue Jan 4 00:54:14 PST 2005
- Previous message: [Slony1-general] Move set
- Next message: [Slony1-general] Move set
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> I'm testing a 3 node Slony-I cluster, and it replicates without problems, > until I try to do a switchover as described in slony-I-failover.txt, by > using the following slonik commands: > > lock set (id = 1, origin = 2); > wait for event (origin = 2, confirmed = 1); > move set (id = 1, old origin = 2, new origin = 1); > wait for event (origin = 2, confirmed = 1); > > Which changes the status of node 2 to provider and node 1 to subscriber, > and > the changes made on node 2 replicates to node 1. But node 3 is completely > lost - the changes on node 2 is not replicated to node 3 and when I look > in > sl_subscribe I can see that it is unaffected by the move set command, as > in > it is still subscribes with node 1 as provider. > > I am using Slony-I 1.0.5 and PostgreSQL 7.4.6. > > Can someone please help me find out what is happening. OK, so can I make a few assumptions and see if they're right? --> I assume that you didn't see any manifest errors in the process of moving the set origin. --> I assume that you're seeing activity go thru fine between nodes 1 and 2, and you're simply not seeing _anything_ happen on node 3. It sorta looks like node 3 is OK; it just isn't getting updated, right? If those are all good assumptions, then the problem is almost certainly that you have a broken/inadequate set of "listen paths." They're in table sl_listen, set up by the STORE LISTEN command. This is listed in the FAQ; you can see a description of a similar scenario here: <http://linuxdatabases.info/info/faq.html#AEN41038> Take a browse of the "Listen Paths" documentation: http://linuxdatabases.info/info/listenpaths.html What you probably need to do is to push in a couple of updates to the listen paths, at which point node 3 will start replicating like mad for a while to catch up. Hopefully a Slonik script with some set of DROP LISTEN and STORE LISTEN statements will do; if not, you might be forced to push them straight in via the stored procedure, e.g. - # select _mycluster.droplisten(1,4,3); # select _mycluster.storelisten(1,2,3); (Where the parameters are based on your local configuration.)
- Previous message: [Slony1-general] Move set
- Next message: [Slony1-general] Move set
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-general mailing list