Как настроить PITR PostgreSQL?

Question

[Solitudine]

Всем привет. Подскажите, если кто-то в курсе и делал подобное.
Есть база, у которой подключена реплика в физическом слоте.
С этой реплики периодически снимаются снапшоты диска целиком (автоматически по расписанию гугле).
Я пытаюсь провернуть Point-in-Time восстановление, развернув доп. виртуалку, подцепив в качестве диска снапшот реплики, дополнительно выкачал с мастера wal-журналы в отдельный каталог и настроил recovery_conf с указанием этого каталога и времени, на которое нужно восстановить.
Но собсна это не работает, база либо в fatal уходит, либо в panic. С ошибками тип

PANIC: could not locate a valid checkpoint record

Или

FATAL:  recovery ended before configured recovery target was reached

Можете подсказать, такой вариант, который я провернуть хочу - вообще работоспособный, и если да, то что я делаю не так. Или же весь процесс построен неправильно, и таким образом PiT не провернуть?
Сам лог с момента запуска с попыткой восстановления выглядит так:

2022-02-10 13:31:29.106 UTC [1515] LOG:  starting PostgreSQL 13.5 (Ubuntu 13.5-2.pgdg20.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, 64-bit
2022-02-10 13:31:29.107 UTC [1515] LOG:  listening on IPv4 address "127.0.0.1", port 5432
2022-02-10 13:31:29.109 UTC [1515] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2022-02-10 13:31:29.115 UTC [1516] LOG:  database system was shut down at 2022-02-10 13:31:25 UTC
cp: cannot stat '/tmp/wal_backup/00000002.history': No such file or directory
2022-02-10 13:31:29.118 UTC [1516] LOG:  starting point-in-time recovery to 2022-02-10 07:00:00+00
2022-02-10 13:31:29.134 UTC [1516] LOG:  restored log file "0000000100000011000000B2" from archive
2022-02-10 13:31:29.349 UTC [1516] LOG:  invalid primary checkpoint record
2022-02-10 13:31:29.349 UTC [1516] PANIC:  could not locate a valid checkpoint record
2022-02-10 13:31:29.564 UTC [1515] LOG:  startup process (PID 1516) was terminated by signal 6: Aborted
2022-02-10 13:31:29.564 UTC [1515] LOG:  aborting startup due to startup process failure
2022-02-10 13:31:29.565 UTC [1515] LOG:  database system is shut down
pg_ctl: could not start server
Examine the log output.

Answer 1

[Melkij]

Для pitr вам нужен:
- basebackup как основа, должно быть завершено его снятие до датывремени требуемого восстановления pitr
- непрерывный архив всех и абсолютно каждого сегмента wal без пропусков от момента checkpoint перед снятием используемого в восстановлении basebackup и до требуемой точки восстановления

database system was shut down at 2022-02-10 13:31:25 UTC
starting point-in-time recovery to 2022-02-10 07:00:00+00

Это, конечно, невозможно даже с корректным архивом WAL.
У postgresql REDO recovery, а не UNDO. Pitr только вперёд от текущей позиции. И не раньше достижения точки консистентности состояния (окончания снятия basebackup)

Чтобы не ходить по граблям консистентности ещё и файловой системы, basebackup предпочтительнее снимать с самого postgresql, а не снимком блочного устройства. Но в целом вариант предусмотренный, ничем неотличимый от обычного crash recovery вроде старта после пропадания электричества (лишь бы fsync работал на всех уровнях корректно и не игнорировался).

Comments

[Solitudine]

Такое время получилось уже после нескольких разных попыток восстановить.
Изначально, когда только монтирую диск со снапшота и сразу пытаюсь запустить pitr, то получается примерно такое

2022-02-11 05:07:39.809 UTC [1111] LOG:  starting PostgreSQL 13.5 (Ubuntu 13.5-2.pgdg20.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, 64-bit
2022-02-11 05:07:39.809 UTC [1111] LOG:  listening on IPv4 address "127.0.0.1", port 5432
2022-02-11 05:07:39.812 UTC [1111] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2022-02-11 05:07:39.820 UTC [1112] LOG:  database system was interrupted while in recovery at log time 2022-02-10 23:02:09 UTC
2022-02-11 05:07:39.820 UTC [1112] HINT:  If this has occurred more than once some data might be corrupted and you might need to choose an earlier recovery target.
cp: cannot stat '/tmp/wal_backup/00000002.history': No such file or directory
2022-02-11 05:07:39.928 UTC [1112] LOG:  starting point-in-time recovery to 2022-02-11 02:00:00+00
2022-02-11 05:07:39.947 UTC [1112] LOG:  restored log file "0000000100000011000000C8" from archive
2022-02-11 05:07:40.143 UTC [1112] LOG:  redo starts at 11/C893A778
2022-02-11 05:07:40.192 UTC [1112] LOG:  restored log file "0000000100000011000000C9" from archive
2022-02-11 05:07:40.358 UTC [1112] LOG:  consistent recovery state reached at 11/C9663E88
2022-02-11 05:07:40.358 UTC [1112] LOG:  invalid resource manager ID 102 at 11/C9663E88
2022-02-11 05:07:40.358 UTC [1112] LOG:  redo done at 11/C9663E50
2022-02-11 05:07:40.358 UTC [1112] LOG:  last completed transaction was at log time 2022-02-10 23:11:54.055611+00
2022-02-11 05:07:40.358 UTC [1112] FATAL:  recovery ended before configured recovery target was reached
2022-02-11 05:07:40.361 UTC [1111] LOG:  startup process (PID 1112) exited with exit code 1
2022-02-11 05:07:40.361 UTC [1111] LOG:  terminating any other active server processes
2022-02-11 05:07:40.364 UTC [1111] LOG:  database system is shut down

Я правильно понял, что при снятии снапшота с диска реплики pitr никак не провернуть?

[Melkij]

Где дальнейшие wal?
Повторюсь, непрерывный архив из всех WAL, в данном случае от 0000000100000011000000C8 и до того неведомого файла, в которым обнаружится первая транзакция после 2022-02-11 02:00:00+00, чтобы остановиться до применения этого wal.

[Solitudine]

С 00..C8 до 00..E7 журналы лежат в каталоге pg_wal.
В /tmp/wal_backup лежат файлы с 00.DA до 00..F9. Т.е. файлы с транзакцией после 2022-02-11 02:00:00+00 находятся в /tmp/wal_backup.

recovery.conf выглядит таким образом:

restore_command = 'cp /tmp/wal_backup/%f %p'
recovery_target_time = '2022-02-11 05:00:00'

[Melkij]

C9 не выглядит дописанным. То есть не был сохранён с primary, когда primary его заполнил. Ну и дырка от E8 до DA никуда не годится. Нет wal - не будет pitr.

[Melkij]

btw,

starting PostgreSQL 13.5
recovery.conf выглядит таким образом:

Одно из двух утверждений ложно. postgresql 13 откажется стартовать, если увидит recovery.conf. Вообще откажется. Я это сделал специально.

[Solitudine]

Самого recovery.conf в каталоге нет, эти строки в postgresql.conf.

Спасиб. По итогу да, виновата была дырка в логах, хоть и до нужного журнала с этой датой были все необходимые, но база видимо пыталась прокрутить весь журнал, чтоб при необходимости продолжить дальше восстановление, и по итогу падало.

В прошлые разы, когда пытался запустить, видимо где-то 1-2 журнала были недописанные и из-за этого падало.