Timeline in the light of Synchronous replication
От | fazool mein |
---|---|
Тема | Timeline in the light of Synchronous replication |
Дата | |
Msg-id | AANLkTi=hpG=uQrsjCtYJT6GJn9gtFRxTzm2YKdbE9SyD@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: Timeline in the light of Synchronous replication
Re: Timeline in the light of Synchronous replication |
Список | pgsql-hackers |
Hello guys,<br /><br />The concept of time line makes sense to me in the case of asynchronous replication. But in case ofsynchronous replication, I am not so sure.<br /><br />When a standby connects to the primary, it checks if both have thesame time line. If not, it doesn't start.<br /><br />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 morphsinto a primary. Now, lets say we start the old primary A as a standby, to connect to the new primary B (which previouslywas a standby). As the code is at the moment, the old primary A will not be allowed to connect to the new primaryB because A's timelineid (1) is not equivalent to that of the new primary B (2). Hence, we need to create a backupagain, and setup the standby from scratch. <br /><br />In the above scenario, if the system was using asynchronousreplication, 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 standbyfrom scratch because of time lines might not be very desirable if the database is huge.<br /><br />Your comments onthe above will be appreciated.<br /><br />Regards<br /><br /><br />
В списке pgsql-hackers по дате отправления: