Re: Timeline in the light of Synchronous replication
От | David Fetter |
---|---|
Тема | Re: Timeline in the light of Synchronous replication |
Дата | |
Msg-id | 20101018012405.GF17565@fetter.org обсуждение исходный текст |
Ответ на | Timeline in the light of Synchronous replication (fazool mein <fazoolmein@gmail.com>) |
Список | 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@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
В списке pgsql-hackers по дате отправления: