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@lists.slony.info > http://lists.slony.info/mailman/listinfo/slony1-general > -- Anyone who trades liberty for security deserves neither liberty nor security. -- Benjamin Franklin _______________________________________________ Slony1-general mailing list Slony1-general@lists.slony.info http://lists.slony.info/mailman/listinfo/slony1-general
