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 <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@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