Thanks Adrian and Edison, I also think so. At the moment I have 2 masters, as soon as slave is promoted to master it starts its own timeline and application might have added data to either of them or both, only way to find out correct master now is the instance with max count of data in tables which could incur data loss as well. Correct me if wrong please?
Thanks and Regards Vikas On Tue, Apr 10, 2018, 17:29 Adrian Klaver <adrian.kla...@aklaver.com> wrote: > On 04/10/2018 08:04 AM, Vikas Sharma wrote: > > Hi Adrian, > > > > This can be a good example: Application server e.g. tomcat having two > > entries to connect to databases, one for master and 2nd for Slave > > (ideally used when slave becomes master). If application is not able to > > connect to first, it will try to connect to 2nd. > > So the application server had a way of seeing the new master(old slave), > in spite of the network glitch, that the original master database did not? > > If so and it was distributing data between the two masters on an unknown > schedule, then as Edison pointed out in another post, you really have a > split brain issue. Each master would have it's own view of the data and > latest update would really only be relevant for that master. > > > > > Regards > > Vikas > > > > On 10 April 2018 at 15:26, Adrian Klaver <adrian.kla...@aklaver.com > > <mailto:adrian.kla...@aklaver.com>> wrote: > > > > On 04/10/2018 06:50 AM, Vikas Sharma wrote: > > > > Hi, > > > > We have postgresql 9.5 with streaming replication(Master-slave) > > and automatic failover. Due to network glitch we are in > > master-master situation for quite some time. Please, could you > > advise best way to confirm which node is latest in terms of > > updates to the postgres databases. > > > > > > It might help to know how the two masters received data when they > > where operating independently. > > > > > > Regards > > Vikas Sharma > > > > > > > > -- > > Adrian Klaver > > adrian.kla...@aklaver.com <mailto:adrian.kla...@aklaver.com> > > > > > > > -- > Adrian Klaver > adrian.kla...@aklaver.com >
