<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This analysis is flawed. The two event numbers are from different origins and therefore, don't compare to each other. The combination of ev_origin,ev_seqno can never be higher on any node, than it is on the origin itself.<br>
<br></blockquote><div>Thanks Jan. For correcting me, let me recheck thoroughly from my side why I concluded on the seqno.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Your disaster recovery plan assumes, that streaming replication will ALLWAYS be faster than Slony replication. But that is only true for synchronous streaming replication. If you use asynchronous streaming replication, then one tiny network glitch and your DR-master will be several seconds behind while the Slony replica may be not. If the master blows up in that moment, your plan fails.<br>
<br></blockquote><div>Yes, very much true and completely agreed. Aim is to not to have any lag between Master & DR-Master. </div><div>As you said, in any case if Master & DR-Master are not in Sync due to network or any lag then my whole plan collapses. So, I made my goal clear here, that I need to STOP slony between Master & Slave long before promoting DR-master as Master, to make sure nothing is left on Master to update on DR-master. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To simulate this problem, Steve and I were pointing out, do the following:<br>
<br>
1. Create your setup as before.<br>
2. Stop the streaming replication (simulating the network communication problem)<br>
3. Update a row on the master and wait for the SYNC to replicate.<br>
4. Stop the slon processes. DO NOT let the streaming replica catch up with the now DEAD master. Assume the master and all its data, including WAL, have become unavailable.<br>
5. Promote DR-master and do the two store path commands.<br>
6. Start slon processes.<br>
7. Update another row on the new master.<br>
8. Compare table content on master and slave.<br>
<br>
You can detect the problem before step 5 by comparing the ev_seqno with ev_origin=old-master on the DR-master and slave. Whichever is higher should be promoted to master. In the unlikely case that it is the Slony slave, you will have to rebuild the DR-master from scratch, though.<span class="HOEnZb"><font color="#888888"><br>
<br></font></span></blockquote><div><br></div><div>Exactly, these are the steps I followed and succeded, as pointed I never simulated Step 2,3 in my testing, because If MASTER and newly promoted DR-Master are not same in any case then the success is nowhere near by surroundings :) .</div>
<div> </div><div>I will surely retake the test with the steps mentioned on my two VM's and update my finding. </div><div><br></div><div>Once again, Thank you very much to you & Steve for helping me in this scenario.</div>
<div> </div><div>--</div></div>Regards<div>Raghav</div><div>Blog: htt://<a href="http://raghavt.blogspot.com/" target="_blank">raghavt.blogspot.com/</a></div><br>