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

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

如果主服务器发生故障，备用服务器成为新的主服务器，然后旧的主服务器重新启动，则必须有一个机制来通知旧的主服务器它不再是主服务器。这有时被称为STONITH（Shoot The Other Node In The Head，即“枪毙另一个节点”），这是为了避免两个系统都认为自己是主服务器的情况，这会导致混乱并最终导致数据丢失。

许多故障转移系统仅使用两个系统：主服务器和备用服务器，它们通过某种心跳机制连接，以持续验证两者之间的连接以及主服务器的可用性。也可以使用第三个系统（称为见证服务器）来防止某些不当故障转移的情况，但除非经过仔细设置和严格测试，否则额外的复杂性可能不值得。

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

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

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

如果您选择了逻辑复制槽同步（请参阅 第 47.2.3 节），那么在切换到备用服务器之前，建议检查备用服务器上同步的逻辑槽是否已准备好进行故障转移。这可以通过按照 第 29.3 节 中描述的步骤来完成。

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