Timeline in the light of Synchronous replication

From: fazool mein <fazoolmein(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Timeline in the light of Synchronous replication
Date: 2010-10-13 23:23:57
Message-ID: AANLkTi=hpG=uQrsjCtYJT6GJn9gtFRxTzm2YKdbE9SyD@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.

Your comments on the above will be appreciated.

Regards

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-10-13 23:47:14 Re: ECPG FETCH readahead
Previous Message Robert Haas 2010-10-13 23:15:18 Re: Per-column collation, work in progress