>
> 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.
>
> Thanks Jan. For correcting me, let me recheck thoroughly from my side why
I concluded on the seqno.


> 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.
>
> Yes, very much true and completely agreed. Aim is to not to have any lag
between Master & DR-Master.
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.


> To simulate this problem, Steve and I were pointing out, do the following:
>
> 1. Create your setup as before.
> 2. Stop the streaming replication (simulating the network communication
> problem)
> 3. Update a row on the master and wait for the SYNC to replicate.
> 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.
> 5. Promote DR-master and do the two store path commands.
> 6. Start slon processes.
> 7. Update another row on the new master.
> 8. Compare table content on master and slave.
>
> 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.
>
>
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 :) .

I will surely retake the test with the steps mentioned on my two VM's and
update my finding.

Once again, Thank you very much to you & Steve for helping me in this
scenario.

--
Regards
Raghav
Blog: htt://raghavt.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20120625/287d3b38/attachment.htm