Postgresql 中文操作指南

如果主服务器发生故障，备用服务器应开始故障转移过程。

如果备用服务器发生故障，则无需进行故障转移。如果可以重启备用服务器，即使是在稍后的时间，也可以立即重启恢复进程，利用可重启恢复。如果无法重启备用服务器，应创建一个全新的备用服务器实例。

如果主服务器发生故障，备用服务器变为新的主服务器，然后旧的主服务器重新启动，则必须具备一种机制来告知旧的主服务器它不再是主服务器。这有时被称为 STONITH（向另一个节点开枪），这是必要的，以避免两种情况：两种系统都认为它们是主服务器，这将导致混乱且最终导致数据丢失。

许多故障转移系统只使用两个系统，即主服务器和备用服务器，它们通过某种心跳机制连接，以持续验证两者之间的连接以及主服务器的可行性。使用第三系统（称为见证服务器）来防止某些不适当的故障转移也是可能的，但如果第三系统未设置得足够谨慎并经过严格测试，其附加的复杂性可能并不值得。

PostgreSQL 不提供识别主服务器上的故障并通知备用数据库服务器所需的系统软件。许多此类工具存在，并且与成功故障转移所需的各种操作系统设施（如 IP 地址迁移）很好地集成在一起。

一旦发生故障转移至备用库，则只有一个服务器处于运行状态。这称为退化状态。以前的备用库现在是主库，但以前的主库已经关闭，并且可能一直关闭。要恢复到正常操作，必须重新创建一个备用服务器，这可以在以前的系统启动时在主系统上进行，或者在第三个（可能是新的）系统上进行。 pg_rewind 实用程序可用于在大型集群上加快此过程。一旦完成，主库和备用库就可以被视为切换了角色。有些人选择使用第三个服务器为新的主库提供备份，直到重新创建新的备用服务器为止，尽管这显然会使系统配置和操作流程复杂化。

所以，从主服务器切换到备用服务器可能很快，但需要一些时间来重新准备故障转移群集。从主服务器定期切换到备用服务器非常有用，因为它允许每个系统定期停机进行维护。这还可以作为故障转移机制的测试，以确保在需要时故障转移机制真正有效。建议制定书面管理程序。

要触发日志传送备用服务器的故障转移，请运行 pg_ctl promote 或调用 pg_promote()。如果您正在设置仅用于从主服务器卸载只读查询的报告服务器，而不是出于高可用性目的，则无需升级。