Re: How should pg_standby get over the gap of timeline?
От | Fujii Masao |
---|---|
Тема | Re: How should pg_standby get over the gap of timeline? |
Дата | |
Msg-id | 3f0b79eb0811201939j6858f99ay16b0d453d6c0f934@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: How should pg_standby get over the gap of timeline? ("Pavan Deolasee" <pavan.deolasee@gmail.com>) |
Список | pgsql-hackers |
On Fri, Nov 21, 2008 at 12:15 AM, Pavan Deolasee <pavan.deolasee@gmail.com> wrote: > > > On Thu, Nov 20, 2008 at 8:36 PM, Heikki Linnakangas > <heikki.linnakangas@enterprisedb.com> wrote: >> >> That seems like a dangerous assumption. What if the standby had fallen >> behind before the failover? It's not safe to failover back to the original >> primary in that case. We'd need some kind of safeguards against that. >> > > For synchronous replication, what if we ensure that the standby has received > the WAL (atleast in its buffers) before writing it to disk on the primary ? > If we do that, I think the old standby can never fall behind the primary and > it would be easy for the old primary to join back the replication without a > fresh backup. In the current patch, since the WAL are written and sent concurrently for the performance gain, we cannot guarantee whether the old standby fall behind or not. I think that the setup procedure which can resolve both cases is required. > Of course, this doesn't work for async replication. Yeah, in asynch replication, some committed transaction may disappear regardless of whether the fresh backup is used or not. But, since the current patch guarantee "Replicate Ahead Log" rule even if asynch case, we can recover the old primary by using the WAL on the old standby consistently. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: