On Sun, 21 Mar 2010, Philippe Clérié wrote:

> So I cannot just restart Node1, restart Slony on both nodes and do MOVE SET?
>
> If I get the docs correctly, FAILOVER assumes the original node is not
> coming back up. Actually it's up but I haven't reconnected it to the
> internet pending a solution to the replication problem.

Since you are restoring node 1 to a backup from three weeks ago you can't 
issue a move set.  Slony won't have a complete record of the changes made to 
your database between your last backup (three weeks ago) and the time your 
server went down.

You want to issue a failover command, then re-add node 1 to your cluster as 
a new node and have slony copy the data from node 2 to node 1 as part of 
the set subscription.

Once node 1 is caught up you could use 'move set' to move the set from node 
2 back to node 1 but you first have to use failover to make node 2 the 
provider and re add+subscribe node 1.

Steve



>
> -- 
>
> Philippe
>
> ------
> The trouble with common sense is that it is so uncommon.
> <Anonymous>
>
> On Sunday 21 March 2010 11:15:00 Guillaume Lelarge wrote:
>> Le 21/03/2010 15:37, Philippe Clérié a écrit :
>>> I am trying to recover from a catastrophe and I am about to do
>>> something new and I need some reassurance that it's the correct
>>> procedure.
>>>
>>> I have a Slony replication set with two nodes in a master/slave
>>> configuration, Postgresql 8.1, Slony 1.2.1 on Debian Etch. Node1
>>> (master) was taken out of commission (think a rm -rf * type error).
>>> I've recovered from a previous backup that's about 3 weeks out of date,
>>> but Node2 is up to date. I want Node2 to update Node1 and then I want
>>> to go back to normal.
>>>
>>> If I understood correctly, according to the docs, the MOVE SET command
>>> is the appropriate saviour. So I want to execute the following script
>>> on Node1:
>>>
>>> cluster name = mycluster;
>>> node 1 admin conninfo='host=xxxxxxx';
>>> node 2 admin conninfo='host=yyyyyyy';
>>> execute script (
>>>    lock set (id = 1, origin = 1);
>>>    wait for event (origin = 1, confirmed = 2);
>>>    move set (id = 1, old origin = 1, new origin = 2);
>>>    wait for event (origin = 1, confirmed = 2);
>>> );
>>>
>>> Taken right out of the book.
>>
>> Nope, if Node 1 is unavailable, you should do a failover (and not a
>> switchover). See failover slonik command
>> (http://www.slony.info/documentation/stmtfailover.html).
>>
>>> I'll a reasonable amount of time (an hour should suffice), then again
>>> on Node1 I would execute the same script but reversing the origins:
>>>
>>> cluster name = mycluster;
>>> node 1 admin conninfo='host=xxxxxxx';
>>> node 2 admin conninfo='host=yyyyyyy';
>>> execute script (
>>>    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);
>>> );
>>
>> This one is good. But you need to wait until they are synchronized.
>>
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general
>
>