Re: Switching timeline over streaming replication
| От | Amit Kapila |
|---|---|
| Тема | Re: Switching timeline over streaming replication |
| Дата | |
| Msg-id | 008901cd9c68$c9bc38e0$5d34aaa0$@kapila@huawei.com обсуждение исходный текст |
| Ответ на | Re: Switching timeline over streaming replication (Josh Berkus <josh@agliodbs.com>) |
| Ответы |
Re: Switching timeline over streaming replication
|
| Список | 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.
В списке pgsql-hackers по дате отправления: