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
> ------------
>   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