PostgreSQL 9.4.1 无恢复的切换和切换回_target_timeline=latest

Posted 2023-03-31

【中文标题】PostgreSQL 9.4.1 无恢复的切换和切换回_target_timeline=latest

【英文标题】：PostgreSQL 9.4.1 Switchover & Switchback without recover_target_timeline=latest

【发布时间】：2019-12-02 09:23:19

【问题描述】：

我已经在 postgreSQL 9.4.1 版本中测试了不同的场景进行切换和切回。

场景一：- PostgreSQL Switchover and Switchback in 9.4.1

场景 2：- Is it mandatory parameter recover_target_timeline='latest' in switchover and switchback in PostgreSQL 9.4.1?

场景 3：-在这个页面上

为了测试场景 3，我按照以下步骤执行。

1) 停止连接到主服务器的应用程序。

2) 确认所有应用程序都已停止，并且所有线程都已与主数据库断开连接。

@192.x.x.129（主要）

3) 使用清理关闭主节点

pg_ctl -D$PGDATA stop --mf

@DR(192.x.x.128) 边检查同步状态：

postgres=# select pg_last_xlog_receive_location(),pg_last_xlog_replay_location(); -[ RECORD 1 ]-----------------+----------- pg_last_xlog_receive_location | 4/57000090 pg_last_xlog_replay_location | 4/57000090

4)停止 DR server.DR(192.x.x.128)

pg_ctl -D $PGDATA stop -mf

pg_log：

2019-12-02 13:16:09 IST LOG: received fast shutdown request 2019-12-02 13:16:09 IST LOG: aborting any active transactions 2019-12-02 13:16:09 IST LOG: shutting down 2019-12-02 13:16:09 IST LOG: database system is shut down

@192.x.x.128(DR)

5) 在 DR 服务器上进行以下更改。

mv recovery.conf recovery.conf_bkp

6)在 192.x.x.129(Primary) 中进行更改：

[postgres@localhost data]$ cat recovery.conf standby_mode = 'on' primary_conninfo = 'user=replication password=postgres host=192.x.x.128 port=5432 sslmode=prefer sslcompression=1 krbsrvname=postgres' restore_command = 'cp %p /home/postgres/restore/%f' trigger_file='/tmp/promote'

7)以读写模式启动DR：

pg_ctl -D $DATA start

pg_log：

2019-12-02 13:20:21 IST LOG: database system was shut down in recovery at 2019-12-02 13:16:09 IST 2019-12-02 13:20:22 IST LOG: database system was not properly shut down; automatic recovery in progress 2019-12-02 13:20:22 IST LOG: consistent recovery state reached at 4/57000090 2019-12-02 13:20:22 IST LOG: invalid record length at 4/57000090 2019-12-02 13:20:22 IST LOG: redo is not required 2019-12-02 13:20:22 IST LOG: database system is ready to accept connections 2019-12-02 13:20:22 IST LOG: autovacuum launcher started (END)

我们可以在上面的日志中看到 OLD 主节点现在是主节点的 DR（它是 OLD DR）并且没有显示任何错误，因为新主节点上的时间线 ID 相同，而新主节点已经在新 DR 中退出。

8)以只读模式启动Primary：-

pg_ctl -D$PGDATA start

日志：

2019-12-02 13:24:50 IST LOG: database system was shut down at 2019-12-02 11:14:50 IST 2019-12-02 13:24:51 IST LOG: entering standby mode cp: cannot stat ‘pg_xlog/RECOVERYHISTORY’: No such file or directory cp: cannot stat ‘pg_xlog/RECOVERYXLOG’: No such file or directory 2019-12-02 13:24:51 IST LOG: consistent recovery state reached at 4/57000090 2019-12-02 13:24:51 IST LOG: record with zero length at 4/57000090 2019-12-02 13:24:51 IST LOG: database system is ready to accept read only connections 2019-12-02 13:24:51 IST LOG: started streaming WAL from primary at 4/57000000 on timeline 9 2019-12-02 13:24:51 IST LOG: redo starts at 4/57000090 (END)

问题 1：- 在这种情况下，我只执行了切换来向您展示。使用这种方法，我们可以进行切换和切回。但是使用下面的方法 Switch-over-switchback 是可行的，那么为什么 PostgreSQL 社区发明 recovery_target_timeline=latest 并应用补丁请参阅博客：https://www.enterprisedb.com/blog/switchover-switchback-in-postgresql-9-3 从 PostgrSQL 9.3...到最新版本。

问题2：-上面的日志cp: cannot stat ‘pg_xlog/RECOVERYHISTORY’: No such file or directory是什么意思？

问题 3：- 我想从场景 1 和场景 3 中确定哪种方法/场景是进行切换和切回的正确方法？因为场景 2 出错了，因为我们必须使用所有社区专家都知道的recover_target_timeline=latest。

【问题讨论】：

使用 9.4.1 是危险的疏忽。你至少要使用9.4.25，而且这个版本很快就会失效，你应该升级。

是的，我已经在 UAT 中升级了。我将在 2020 年 1 月升级到 11.5。

【参考方案1】：

答案：

如果你彻底关闭了standby，然后删除recovery.conf并重新启动它，它会出现，但必须执行崩溃恢复（database system was not properly shut down）。

将备用数据库提升为主数据库的正确方法是使用触发器文件或运行pg_ctl promote（或者，从v12 开始，通过运行SQL 函数pg_promote）。这样您就没有停机时间，也不需要执行崩溃恢复。

提升待机会使其选择新的时间线，因此如果您希望新的待机遵循该时间线切换，则需要recovery_target_timeline = 'latest'。

那是你的restore_command造成的。

上面1.中的方法是正确的。

【讨论】：

你能澄清第 1 个答案吗？假设天气我删除或 mv 到另一个，待机将开始遵循时间线。我们可以说没有 recovery_target_timeline 我们可以进行切换和切回。因为我们在这个（场景 3）中也没有丢失任何检查点。我想知道这有什么问题。？我的朋友说他已经使用场景 3 完成了切换和切换（DB 大小 500GB）。

使用场景 3，我可以保留存档日志序列，以恢复数月以上的存档。 （这里时间线ID没有改变）

我不明白你的第一条评论。是的，可以按照您建议的方式进行故障转移，但是数据库的工作量更大并且需要更长的时间。您的方法也没有任何好处。您可以通过时间线切换恢复备份和恢复。