Re: Archive recovery won't be completed on some situation.
От | Heikki Linnakangas |
---|---|
Тема | Re: Archive recovery won't be completed on some situation. |
Дата | |
Msg-id | 532977FE.70204@vmware.com обсуждение исходный текст |
Ответ на | Re: Archive recovery won't be completed on some situation. (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: Archive recovery won't be completed on some situation.
Re: Archive recovery won't be completed on some situation. |
Список | pgsql-hackers |
On 03/19/2014 10:28 AM, Kyotaro HORIGUCHI wrote: > The*problematic* operation sequence I saw was performed by > pgsql-RA/Pacemaker. It stops a server already with immediate mode > and starts the Master as a Standby at first, then > promote. Focusing on this situation, there would be reasonable to > reset backup positions. Well, that's scary. I would suggest doing a fast shutdown instead. But if you really want to do an immediate shutdown, you should delete the backup_label file after the shutdown When restarting after immediate shutdown and a backup_label file is present, the system doesn't know if the system crashed during a backup, and it needs to perform crash recovery, or if you're trying restore from a backup. It makes a compromise, and starts recovery from the checkpoint given in the backup_label, as if it was restoring from a backup, but if it doesn't see a backup-end WAL record, it just starts up anyway (which would be wrong if you are indeed restoring from a backup). But if you create a recovery.conf file, that indicates that you are definitely restoring from a backup, so it's more strict and insists that the backup-end record must be replayed. > 9.4 canceles backup mode even on > immediate shutdown so the operation causes no problem, but 9.3 > and before are doesn't. Hmm, I don't think we've changed that behavior in 9.4. - Heikki
В списке pgsql-hackers по дате отправления: