recovery starting when backup_label exists, but not recovery.signal
От | Fujii Masao |
---|---|
Тема | recovery starting when backup_label exists, but not recovery.signal |
Дата | |
Msg-id | CAHGQGwEYYg_Ng+03FtZczacCpYgJ2Pn=B_wPtWF+FFLYDgpa1g@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: recovery starting when backup_label exists, but notrecovery.signal
|
Список | pgsql-hackers |
Hi, 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. 4. the server shuts down.. 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. One idea to fix this issue is to make the above step #3 remember that backup_label existed, in pg_control. Then we should make the subsequent recovery enter an archive recovery mode if pg_control indicates that even if neither backup_label nor recovery.signal exist. Thought? Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: