PostgreSQL故障回退：恢复旧主库为主并最小化数据丢失与传输

根据IBM文档定义，failback（故障回退）是指在灾难或计划维护后将生产环境恢复至原始位置的过程；而在PostgreSQL社区讨论中，故障转移后将旧主库作为新主库的备库重新上线也被视为故障转移的一种。

我拥有两台配置异构的服务器：高性能的Costanza和性能普通的Kramer，无法遵循主备服务器配置一致的最佳实践。当前需要优化的故障回退场景流程如下：

• Costanza进入不可恢复故障状态
• Kramer被提升为primary（主库）
• Costanza恢复可用且PGDATA完整
• 同步Costanza与Kramer，确保Kramer上的数据无丢失
• 将Costanza重新提升为primary
• 将Kramer设置为standby（备库）

我重点关注步骤4和5的优化。经研究发现，使用pg_rewind重放WAL文件时，源服务器在最新共同检查点之后的修改会被忽略，这些修改必须等目标服务器成为源服务器的备库后才能恢复。因此仅运行pg_rewind无法完成完整同步——Kramer上可能存在共同检查点之后的写入操作，这一点也和我们的故障回退演练结果一致。

当前解决方案流程 #

4a. 运行pg_rewind同步分歧时间线
4b. 将Costanza设置为Kramer的备库，追平复制延迟（处理检查点后的WAL文件）
5. 关闭Kramer并将Costanza提升为主库（再次引发时间线分歧）
6a. 以Kramer为目标运行pg_rewind
6b. 将Kramer设置为Costanza的备库，追平复制延迟

由于数据库规模庞大，我希望尽可能避免通过基础备份传输数据，但当前方案需要两次运行pg_rewind，且必须将Costanza设为Kramer的备库来应用检查点后的修改，整体效率较低。同时我需要确保数据丢失最小化，当前方案虽能满足该要求，但仍有以下疑问：

• 是否有无需将Costanza设为Kramer备库即可应用其检查点后修改的方法？
• 是否存在更简短、易执行的等效方案？
• 额外时间线的生成是否需要关注？（这似乎在提升主库时不可避免）

内容的提问来源于stack exchange，提问作者Anthony O