On 12-06-21 11:27 PM, Raghav wrote:
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.
You can use the built-in streaming replication for what you describe but
if you want unplanned failover it should be the SYNCHRONOUS replication.
asynchronous replication will work fine for a controlled switchover
(stop the slons, let your 'DR Master' get caught up with streaming
replication' then bring it up as a read-write node and restart the slons).
However if you have an unplanned failure of your 'master' node the
'slave' node might be further ahead via slony than your 'dr master' node
via async streaming replication. If this happens and you promote the
'DR master' then you might have a very bad day.
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
500017
(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