如果主服务器出现故障，则备用服务器应开始故障转移程序。

如果备用服务器出现故障，则无需进行故障转移。如果备用服务器可以重新启动（即使在一段时间后），则恢复过程也可以立即重新启动，利用可重启的恢复功能。如果备用服务器无法重新启动，则应创建新的全备用服务器实例。

如果主服务器出现故障，并且备用服务器成为了新的主服务器，那么在旧主服务器重新启动之后，你必须使用某种机制来通知旧主服务器它不再是主服务器。这有时被称为STONITH(直接终止目标节点)，这对于避免两种情况都是主服务器的情况非常必要，这将导致混乱，并最终导致数据丢失。

许多故障转移系统仅使用两个通过某种心跳机制连接的主系统和备用系统，以持续验证两系统之间的连接和主系统的 viability（可行性）。也可以使用第三个系统（称为见证服务器）来防止某些情况下不恰当的故障转移，但是额外的复杂性可能不值得，除非在充分小心和严格测试的情况下进行设置。

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

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

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

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

要触发日志传送备用服务器故障切换，运行 pg_ctl promote 或调用 pg_promote()。如果您正在设置仅用于从主数据库卸载只读查询的报告服务器（不用于高可用性目的），则无需提升权限。