Re: Probable problem with pg_standby
От | Fujii Masao |
---|---|
Тема | Re: Probable problem with pg_standby |
Дата | |
Msg-id | 3f0b79eb0811040450s3d126333s2593a3bd15baba58@mail.gmail.com обсуждение исходный текст |
Ответ на | Probable problem with pg_standby (Detlef Ulherr <Detlef.Ulherr@sun.com>) |
Ответы |
Re: Probable problem with pg_standby
|
Список | pgsql-hackers |
On Tue, Nov 4, 2008 at 8:09 PM, Detlef Ulherr <Detlef.Ulherr@sun.com> wrote: > All I did was forcing the primary in a recovery to generate a new timeline. > The installed version was 8.3.4, but the problem is the same with earlier > versions as well. It occurred in 8.2 also. this problem is reproducible all > the times. For my agent code I implemented a workaround which guarantees > that during a resilvering process the primary and the standby start at t the > same timeline. But my feeling is that the standby should go to the same > timeline as the primary when he receives the history file without > disruption, and by all means it should never stop the recovery unmotivated. > This will make a full synchronization necessary and in times of larger > databases, this may cause major downtimes. I agree with you only if normal archive recovery case (not specified recovery_target_xid/time). But, in point-in-time recovery case, the standby cannot continue to redo without stopping. DBA has to reconstruct the standby (get new online-backup with new timeline ID, locate it on the standby and restart recovery). Or, we should deal with normal archive recovery and point-in-time one separately? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: