PostgreSQL PITR не работает должным образом

Question

Я пытаюсь восстановить базу данных PostgreSQL на определенный момент времени.

Когда я использую только restore_command в recovery.conf, тогда она работает нормально.

restore_command = 'cp /var/lib/pgsql/pg_log_archive/%f %p'

КогдаЯ использую recovery_target_time parameter, он не восстанавливается до целевого времени.

restore_command = 'cp /var/lib/pgsql/pg_log_archive/%f %p'
recovery_target_time='2018-06-05 06:43:00.0'

Ниже приведено содержимое файла журнала:

2018-06-05 07:31:39.166 UTC [22512] LOG:  database system was interrupted; last known up at 2018-06-05 06:35:52 UTC
2018-06-05 07:31:39.664 UTC [22512] LOG:  starting point-in-time recovery to 2018-06-05 06:43:00+00
2018-06-05 07:31:39.671 UTC [22512] LOG:  restored log file "00000005.history" from archive
2018-06-05 07:31:39.769 UTC [22512] LOG:  restored log file "00000005000000020000008F" from archive
2018-06-05 07:31:39.816 UTC [22512] LOG:  redo starts at 2/8F000028
2018-06-05 07:31:39.817 UTC [22512] LOG:  consistent recovery state reached at 2/8F000130
2018-06-05 07:31:39.818 UTC [22510] LOG:  database system is ready to accept read only connections
2018-06-05 07:31:39.912 UTC [22512] LOG:  restored log file "000000050000000200000090" from archive
2018-06-05 07:31:39.996 UTC [22512] LOG:  recovery stopping before abort of transaction 9525, time 2018-06-05 06:45:02.088502+00
2018-06-05 07:31:39.996 UTC [22512] LOG:  recovery has paused

Я пытаюсь восстановить экземпляр базы данных.до 06:43:00Почему происходит восстановление до 06: 45: 02?

РЕДАКТИРОВАТЬ

В первом сценарии recovery.conf преобразуется в recovery.done, но во втором случае этого не произошлосценарий

Что может быть причиной этого?

Answer 1

Вы забыли установить

recovery_target_action = 'promote'

После восстановления на момент времени recovery_target_action определяет, как будет работать PostgreSQL.

Значение по умолчанию:pause, что означает, что PostgreSQL ничего не будет делать и будет ждать, пока вы сообщите ему, как действовать.

Чтобы завершить восстановление, подключитесь к базе данных и запустите

SELECT pg_wal_replay_resume();

Кажется, чтомежду 06:43:00 и 06:45:02 не было зарегистрировано ни одной активности базы данныхЗаметьте, что в журнале написано recovery stopping <strong>before</strong> abort of transaction 9525.