当 postgresql 发现触发器文件并将它自己从从服务器提升到主服务器时，实际发生了什么？

Question

我在两个 postgres 服务器（主服务器：服务器 A，从服务器：服务器 B）之间进行了流式复制设置。我想知道当我触摸触发器文件并且从设备接管作为主设备时，引擎盖下实际发生了什么？我想知道的一件事是，在教程或文档中似乎没有人提到任何地方，如果我在完成后重新启动以前的奴隶（现在是主人）怎么办？事情不会变得一团糟，因为 .conf 文件仍然反映了旧的从站设置（例如 hot_standby = on）？在我可以安全地重新启动服务器之前，我应该更新那个 .conf 吗？

背景：我所处的情况让我想知道这一切是我需要更换我主控上的硬盘。这是我打算这样做的方式：

• 故障转移到从站（服务器 B）
• 更改主（服务器 A）上的硬盘并重新安装
• 将重新安装的服务器A作为slave启动
• A服务器赶上B服务器后，将A服务器改回master，然后再把B服务器改回slave

（顺便说一句。如果您对更好的工作流程有建议，请告诉我）

Answer 1

副本服务器（无论是否作为 hot_standby 运行）正在 PostgreSQL 所谓的“恢复模式”下运行。顾名思义，这最初是为了从不安全的停止中执行恢复而开发的：在这种情况下，它使用recovery.conf定义如何查找事务日志（pg_xlog 文件）的文件并继续应用它们直到不再可用，然后退出恢复模式进入“正常”模式，并开始自己生成新的事务日志。退出恢复模式时，recovery.conf文件被重命名为recovery.done，以便后续重启直接进入正常模式。

对于复制从站，此过程的更改是：

• 事务日志数据可能不是来自日志文件，而是来自主服务器：recovery.conf 指定哪个
• 当没有更多数据可用时，副本不会退出恢复模式，它们会等到触发器被触发。

So due to the renaming of recovery.conf, restarting your newly-elected master preserves the property of it being a master.

但是，有一点需要注意：在恢复完成并且服务器从恢复状态转换为正常模式后，它会更改“时间线”。从本质上讲，此时您已经对数据库进行了分叉：一个版本可能是来自任何地方的事务日志的延续，一个版本（新版本）来自刚刚完成恢复的数据库。但是您只能应用来自同一时间线上的主服务器的日志文件！这就是为什么在执行故障转移后，您需要从新主服务器重建旧主服务器，而不是仅仅启动它以让它“赶上”。

（由于我目前在故障转移方面的经验有限，因此上一段存在一些疑问，但这是根据我对文档的理解以及系统的整体工作方式）。

另请注意，该hot_standby标志仅表示数据库集群将接受连接并允许只读查询，即使它处于恢复模式：对于从崩溃中恢复的数据库来说，这不是正常情况。一旦服务器以“正常模式”运行，此设置就无关紧要，因此在旧从站/新主站上设置它不是问题。