PITR 后 recovery.conf 未更改为 recovery.done

Posted 2023-03-06

【中文标题】PITR 后 recovery.conf 未更改为 recovery.done

【英文标题】：recovery.conf not getting changed to recovery.done after PITR

【发布时间】：2018-09-06 07:20:41

【问题描述】：

在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 是 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】：

如您所见，达到目标后恢复暂停。

这是因为您有 hot_standby = on 并且您将 recovery_target_action 保留为默认值 pause。

您必须在recovery.conf中添加以下内容：

recovery_target_action = promote

或者，您可以连接到恢复服务器并手动完成恢复：

SELECT pg_wal_replay_resume();

要解开添加时区为何会产生影响的谜团，请将日志中的时区 (EDT) 与您使用的时区 (EST) 进行比较。

您的数据库在东部夏令时间运行，与 UTC 相差 -4 小时，而东部标准时间 偏移 -5 小时。

所以发生的事情是，通过使用“EST”，您实际上指定了一个对应于2018-09-07 04:25:46 EDT 的恢复目标时间，这已经超过了 WAL 的结束，因此 PostgreSQL 进行了完全恢复。

【讨论】：

这很棒。它现在对我有用。非常感谢您的帮助。