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
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 |