Re: Recovery target 'immediate'

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Recovery target 'immediate'
Дата
Msg-id CAB7nPqT5M=AXRsnFk7jKbyOmVZ6TYtJqtt2pfi=A3fQgurXsZw@mail.gmail.com
обсуждение исходный текст
Ответ на Recovery target 'immediate'  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список pgsql-hackers



On Fri, Apr 19, 2013 at 3:11 AM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
I just found out that if you use continuous archiving and online backups, it's surprisingly difficult to restore a backup, without replaying any more WAL than necessary.

If you don't set a recovery target, PostgreSQL will recover all the WAL it finds. You can set recovery target time to a point immediately after the end-of-backup record, but that's tricky. You have to somehow find out the exact time when the backup ended, and set it to that. But if you set it any too early, recovery will abort with "requested recovery stop point is before consistent recovery point" error. And that's not quite precise anyway; not all record types carry timestamps, so you will always replay a few extra records until the first timestamped record comes along. Setting recovery_target_xid is similarly difficult. If you were well prepared, you created a named recovery point with pg_create_restore_point() immediately after the backup ended, and you can use that, but that requires forethought.

It seems that we're missing a setting, something like recovery_target = 'immediate', which would mean "stop as soon as consistency is reached". Or am I missing some trick?
+1. This will be really helpful. I don't know either of any good way to stop immediately after a consistent point now without tricking a target just after the end of backup.
--
Michael

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

Предыдущее
От: Sergey Burladyan
Дата:
Сообщение: Re: Recovery target 'immediate'
Следующее
От: David Gudeman
Дата:
Сообщение: minimizing the target list for foreign data wrappers