Skip site navigation (1) Skip section navigation (2)

Re: Switching timeline over streaming replication

From: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
To: "'Josh Berkus'" <josh(at)agliodbs(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Switching timeline over streaming replication
Date: 2012-09-27 04:30:12
Message-ID: 008901cd9c68$c9bc38e0$5d34aaa0$@kapila@huawei.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thursday, September 27, 2012 6:30 AM Josh Berkus wrote:
> >   Yes that is correct. I thought timeline change happens only when
> somebody
> > does PITR.
> >   Can you please tell me why we change timeline after promotion,
> because the
> > original
> >   Timeline concept was for PITR and I am not able to trace from code
> the
> > reason
> >   why on promotion it is required?
> 
> The idea behind the timeline switch is to prevent a server from
> subscribing to a master which is actually behind it.  For example,
> consider this sequence:
> 
> 1. M1->async->S1
> 2. M1 is at xid 2001 and fails.
> 3. S1 did not receive transaction 2001 and is at xid 2000
> 4. S1 is promoted.
> 5. S1 processed an new, different transaction 2001
> 6. M1 is repaired and brought back up
> 7. M1 is subscribed to S1
> 8. M1 is now corrupt.
> 
> That's why we need the timeline switch.

Thanks.
I understood this point, but currently in documentation of Timelines, this usecase is not documented (Section 24.3.5).

With Regards,
Amit Kapila.



In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-09-27 04:48:39
Subject: Re: Re: [WIP] Performance Improvement by reducing WAL for Update Operation
Previous:From: Kohei KaiGaiDate: 2012-09-27 04:06:41
Subject: Re: [v9.3] Extra Daemons (Re: elegant and effective way for running jobs inside a database)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group