On Wed, Oct 13, 2010 at 04:23:57PM -0700, fazool mein wrote: > Hello guys, > > The concept of time line makes sense to me in the case of asynchronous > replication. But in case of synchronous replication, I am not so sure. > > When a standby connects to the primary, it checks if both have the same time > line. If not, it doesn't start. > > Now, consider the following scenario. The primary (call it A) fails, the > standby (call it B), via a trigger file, comes out of recovery mode > (increments time line id to say 2), and morphs into a primary. Now, lets say > we start the old primary A as a standby, to connect to the new primary B > (which previously was a standby). As the code is at the moment, the old > primary A will not be allowed to connect to the new primary B because A's > timelineid (1) is not equivalent to that of the new primary B (2). Hence, we > need to create a backup again, and setup the standby from scratch.
Yes. > In the above scenario, if the system was using asynchronous > replication, time lines would have saved us from doing something > wrong. But, if we are using synchronous replication, we know that > both A and B would have been in sync before the failure. In this > case, forcing to create a new standby from scratch because of time > lines might not be very desirable if the database is huge. One way to get them in sync without starting from scratch is to use rsync from A to B. This works in the asynchronous case, too. :) Cheers, David. -- David Fetter <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers