:-) Got it! Thank you very much!
The trouble with these programs is that they work so well you rarely get a chance to know them. Install and forget. :-) -- Philippe ------ The trouble with common sense is that it is so uncommon. <Anonymous> On Sunday 21 March 2010 14:07:53 Steve Singer wrote: > 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 > > [email protected] > > http://lists.slony.info/mailman/listinfo/slony1-general > _______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
