Re: Timeline in the light of Synchronous replication

From: David Fetter <david(at)fetter(dot)org>
To: fazool mein <fazoolmein(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Timeline in the light of Synchronous replication
Date: 2010-10-18 01:24:05
Message-ID: 20101018012405.GF17565@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2010-10-18 02:15:36 Re: Debugging initdb breakage
Previous Message KaiGai Kohei 2010-10-18 00:57:53 Re: security hook on table creation