cbbrowne at ca.afilias.info cbbrowne
Tue Jan 4 00:54:14 PST 2005
> 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.)



More information about the Slony1-general mailing list