On 6/21/2012 11:27 PM, Raghav wrote:
>
>         Q: What I want to achieve ?
>         A:  Swap the Masters. Means, now slave should receive events from
>         DR-Master once it get promoted to Master as shown below
>
>
>     Have you read 'Controlled Switchover'
>     http://www.slony.info/__documentation/2.1/failover.__html
>     <http://www.slony.info/documentation/2.1/failover.html>
>
>     I think the MOVE SET command is what you want.
>
>     You setup 'DR Master' as a subscriber to your sets just like 'slave'
>     was.  You then MOVE SET to make 'DR Master' the new origin.  'slave'
>     will receive updates from 'DR Master' instead of 'Master' , assuming
>     you have a complete path network in place.
>
> Thank you Steve. Make sense to me.
>
> Sorry to say, my question was how to avoid resubscribing DR-Master to
> slave and then promoting it to master. Since, complete information of
> master is available on dr-master.
>
> Due to my curiosity level :)  I tested again with different approach.
> Since, DR Master is Streaming replication READ-ONLY server it will have
> same _slonyschema of all what's there on Master, just the connection
> string changes needed. So, I thought changing the connection string
> should fix.

Using streaming replication for the DR Master could present a problem. 
Since it is in the same data center the following may seem unlikely. But 
what can happen is that the DR Master is further behind in replication 
than the Slony Slave at the moment, disaster strikes and the Master 
becomes unavailable. We never know ahead what will cause the Master to 
go down and how fast it will be.

What if the death is affecting the network interface of Master first. At 
first it is just losing a few packets and some of them are packets from 
the WAL sender to the DR Master. It will take several seconds for the 
TCP/IP protocol to detect that and retransmit. Time enough for several 
more transactions to commit and Slony to replicate them. And before the 
DR Master can catch up, the motherboard finally fails with a puff of smoke.

What will happen with your below steps in this situation is that the 
Slave has some changes, that the DR Master doesn't have. The DR Master 
(now Master) will generate new SYNC events and the first (few) will have 
the same event number as ones, that the Slave had replicated from the 
old Master. They will be ignored by the Slave. So at the end the DR 
Master will be missing some changes made to the old Master and the Slave 
will be missing other changes that had been made against the DR Master.


Jan

>
> I read this part of documentation and implemented below steps not for
> once, couple of times, this time it never failed.
> http://slony.info/documentation/2.1/stmtstorepath.html
>
> 1. Stop slon on Master/Slave
> 2. change store paths with function on DR-master.
> aquent_cdb=# select _myrep.storepath(1,2,'host=*dr-master.com
> <http://dr-master.com>* dbname=master user=postgres port=5432',10);
> ///Note: previsouly it was from master.com <http://master.com>
>   storepath
> ------------
>   5000000017
> (1 row)
> 4. Repeat the step 3 on slave to change the provider info.
> 5. Start slon on DR-Master/slave.
>
> Above steps, went fine and all write operations on dr-master(newly
> promoted as master) started publishing on slave.
> Correct me if this approach is doable.
>
> --Raghav
>
>
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general
>


-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin