Re: recovery starting when backup_label exists, but not recovery.signal

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: recovery starting when backup_label exists, but not recovery.signal
Дата
Msg-id CAHGQGwF3kANe2EcpVZmD4S+iL+0EAAFsEcNVYVwt1WNAe=886g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: recovery starting when backup_label exists, but not recovery.signal  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: recovery starting when backup_label exists, but notrecovery.signal  (David Steele <david@pgmasters.net>)
Список pgsql-hackers
On Fri, Sep 27, 2019 at 4:07 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Fri, Sep 27, 2019 at 3:36 AM David Steele <david@pgmasters.net> wrote:
> >
> > On 9/24/19 1:25 AM, Fujii Masao wrote:
> > >
> > > When backup_label exists, the startup process enters archive recovery mode
> > > even if recovery.signal file doesn't exist. In this case, the startup process
> > > tries to retrieve WAL files by using restore_command. Then, at the beginning
> > > of the archive recovery, the contents of backup_label are copied to pg_control
> > > and backup_label file is removed. This would be an intentional behavior.
> >
> > > But I think the problem is that, if the server shuts down during that
> > > archive recovery, the restart of the server may cause the recovery to fail
> > > because neither backup_label nor recovery.signal exist and the server
> > > doesn't enter an archive recovery mode. Is this intentional, too? Seems No.
> > >
> > > So the problematic scenario is;
> > >
> > > 1. the server starts with backup_label, but not recovery.signal.
> > > 2. the startup process enters an archive recovery mode because
> > >     backup_label exists.
> > > 3. the contents of backup_label are copied to pg_control and
> > >     backup_label is deleted.
> >
> > Do you mean deleted or renamed to backup_label.old?
> >
> > > 4. the server shuts down..
> >
> > This happens after the cluster has reached consistency?
> >
> > > 5. the server is restarted. neither backup_label nor recovery.signal exist.
> > > 6. the startup process starts just crash recovery because neither backup_label
> > >     nor recovery.signal exist. Since it cannot retrieve WAL files from archival
> > >     area, it may fail.
> >
> > I tried a few ways to reproduce this but was not successful without
> > manually removing WAL.
>
> Hmm me too. I think that since we enter crash recovery at step #6 we
> don't retrieve WAL files from archival area.
>
> But I reproduced the problem Fujii-san mentioned that the restart of
> the server during archive recovery causes to the crash recovery
> instead of resuming the archive recovery.

Yes, it's strange and unexpected to start crash recovery
when restarting archive recovery. Archive recovery should
start again in that case, I think.

Regards,

-- 
Fujii Masao



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: recovery starting when backup_label exists, but not recovery.signal
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: pg_wal/RECOVERYHISTORY file remains after archive recovery