We had the same problem today: switchover node 5 to node 1 and watch that
all other nodes are not resubscribed: they are still subscribed to 5. So, we
got a cascaded replication instead of the master switchover.

So, could you please update the documentation at
http://slony.info/documentation/failover.html adding the advice to execute
SUBSCRIBE SET after MOVE SET if an user just want to move his master to
another node?

lock set (id =3D 1, origin =3D 1);
wait for event (origin =3D 1, confirmed =3D 2);
move set (id =3D 1, old origin =3D 1, new origin =3D 2);
wait for event (origin =3D 1, confirmed =3D 2);
...
subscribe set (id =3D 1, provider =3D 2, receiver =3D 3, forward =3D yes);
subscribe set (id =3D 1, provider =3D 2, receiver =3D 4, forward =3D yes);
...



On Wed, May 13, 2009 at 6:46 PM, Christopher Browne <
cbbrowne at ca.afilias.info> wrote:

> Laurent Laborde wrote:
>
>> BIG PS : That was my biggest concern. i wasn't 100% that lock set will
>> or will not lock the slave too.
>> it never lock the slaves, so you can keep your slave in production
>> while moving the master :)
>> yay \o/
>>
>>
> The really essential thing about LOCK SET is that it eliminates the abili=
ty
> to enter *new* replication data.  It locks the origin down so that there's
> no extra replication data to "slip in sideways" that could get lost when =
you
> switch the origin.
>
> On subscriber nodes, the tables were already "locked" against updates (see
> the "denyaccess" triggers), so LOCK SET is effectively a no-op on them.
>
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20090705/=
f7bf5097/attachment.html