recovery.conf не меняется на recovery.done после PITR - PullRequest
Новая
       54

recovery.conf не меняется на recovery.done после PITR

0 голосов
/ 06 сентября 2018

В recovery.conf, если мы передадим recovery_target_time как 2018-09-07 03:25:46 (без EST) и перезапустим PostgreSQL, recovery.conf не изменится на recovery.done.

Тем не менее, PITR успешен, и записи / таблицы восстанавливаются только до определенного времени. Но затем база данных остается в режиме восстановления, и я не могу изменить данные.

Во втором случае, если я добавлю EST и перезапущу PostgreSQL, recovery.conf изменится на recovery.done, но все восстановится. Я имею в виду таблицы / записи, добавленные после 2018-09-07 03:25:46, также восстановлены.

Другая информация: делать это на хосте Linux. Timezone in postgresql.conf is US/Eastern

postgresql.conf имеет следующие настроенные параметры. Другие варианты закомментированы. 

listen_addresses = '*'
port = 5432
max_connections = 100
shared_buffers = 128MB
dynamic_shared_memory_type = posix
wal_level = replica
archive_mode = on
archive_command = 'cp %p /archive/%f'
log_destination = 'stderr'
logging_collector =on
log_timezone = 'US/Eastern'
datestyle = 'iso, mdy'
timezone ='US/Eastern'
lc_messages = 'en_US.UTF-8'
lc_monetary ='en_US.UTF-8'
lc_numeric = 'en_US.UTF-8'
lc_time = 'en_US.UTF-8'
default_text_search_config = 'pg_catalog.english'

Для recovery.conf доступны следующие две опции: 

restore_command = 'cp /archive/%f %p'
recovery_target_time = '2018-09-07 03:25:46'


2018-09-07 03:35:57.745 EDT [8264] LOG:  database system was interrupted; last known up at 2018-09-07 03:23:31 EDT
2018-09-07 03:35:59.593 EDT [8264] LOG:  starting point-in-time recovery to 2018-09-07 03:25:46-04
2018-09-07 03:35:59.682 EDT [8264] LOG:  restored log file "000000010000000000000003" from archive
2018-09-07 03:35:59.722 EDT [8264] LOG:  redo starts at 0/3000028
2018-09-07 03:35:59.725 EDT [8264] LOG:  consistent recovery state reached at 0/3000130
2018-09-07 03:35:59.725 EDT [8262] LOG:  database system is ready to accept read only connections
2018-09-07 03:36:00.058 EDT [8264] LOG:  restored log file "000000010000000000000004" from archive
2018-09-07 03:36:00.097 EDT [8264] LOG:  recovery stopping before commit of transaction 562, time 2018-09-07 03:26:17.435255-04
2018-09-07 03:36:00.097 EDT [8264] LOG:  recovery has paused
2018-09-07 03:36:00.097 EDT [8264] HINT:  Execute pg_wal_replay_resume() to continue.
2018-09-07 03:36:54.138 EDT [8288] ERROR:  cannot execute CREATE TABLE in a read-only transaction
2018-09-07 03:36:54.138 EDT [8288] STATEMENT:  CREATE TABLE scale_data5 ( section NUMERIC NOT NULL, id1 NUMERIC NOT NULL, id2 NUMERIC NOT NULL );

1 Ответ

0 голосов
/ 07 сентября 2018

Как видите, восстановление останавливается после достижения цели.

Это потому, что у вас есть hot_standby = on и вы оставили recovery_target_action со значением по умолчанию pause.

Вы должны добавить следующее в recovery.conf: 

recovery_target_action = promote

Кроме того, вы можете подключиться к восстанавливающему серверу и завершить восстановление вручную: 

SELECT pg_wal_replay_resume();

Чтобы решить загадку, почему добавление часового пояса имеет значение, сравните часовой пояс в журнале (EDT) с часовым поясом, который вы использовали (EST).

Ваша база данных работает в Восточное летнее время , которое смещено на 4 часа от UTC, тогда как Восточное стандартное время - смещение -5 часов.

Итак, с помощью & ldquo; EST & rdquo; вы фактически указали целевое время восстановления, соответствующее 2018-09-07 04:25:46 EDT, которое прошло после окончания WAL, поэтому PostgreSQL полностью восстановил.

...