Re: Switching timeline over streaming replication
От | Josh Berkus |
---|---|
Тема | Re: Switching timeline over streaming replication |
Дата | |
Msg-id | 5063A50E.4090607@agliodbs.com обсуждение исходный текст |
Ответ на | Re: Switching timeline over streaming replication (Amit Kapila <amit.kapila@huawei.com>) |
Ответы |
Re: Switching timeline over streaming replication
|
Список | pgsql-hackers |
> 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. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
В списке pgsql-hackers по дате отправления: