backup_label and server start
От | Albe Laurenz |
---|---|
Тема | backup_label and server start |
Дата | |
Msg-id | D960CB61B694CF459DCFB4B0128514C293CEB7@exadv11.host.magwien.gv.at обсуждение исходный текст |
Ответы |
Re: backup_label and server start
Re: backup_label and server start |
Список | pgsql-hackers |
If the postmaster is stopped with 'pg_ctl stop' while an online backup is in progress, the 'backup_label' file will remain in the data directory. There is no recovery.conf file present. When the server is started again, it attempts to recover from the checkpoint marked in the backup_label file even if the shutdown was clean. If the WAL file mentioned in backup_label is not in pg_xlog (it has already been archived and removed because there was enough database activity since pg_start_backup()), the startup process will fail with a message like this: LOG: could not open file "pg_xlog/000000020000000000000084" (log file 0, segment 132): No such file or directory LOG: invalid checkpoint record PANIC: could not locate required checkpoint record HINT: If you are not restoring from a backup, try removing the file "/POSTGRES/data/PG820/backup_label". My question: Is it safe to just delete the file as the hint suggests? I see the following comment in src/backend/access/transam/xlog.c: /** read_backup_label: check to see if a backup_label file is present** If we see a backup_label during recovery, we assumethat we are recovering* from a backup dump file, and we therefore roll forward from the checkpoint* identified by thelabel file, NOT what pg_control says. This avoids the* problem that pg_control might have been archived one or morecheckpoints* later than the start of the dump, and so if we rely on it as the start* point, we will fail to restore aconsistent database state. "We will fail to restore a consistent database state" sounds rather intimidating. *If* - on the other hand - it is safe to follow the hint and remove the backup_label, wouldn't it be a good thing for the startup process to ignore (and rename) the backup_label file if no recovery.conf is present? Or, alternatively, the backup_label file could by removed by a clean shutdown. Thanks, Laurenz Albe
В списке pgsql-hackers по дате отправления: