如果主库失效，备库就应该开始执行故障转移过程。

如果备库失效，则不需要发生故障转移。如果备库能够重新启动，即使是在稍后某个时间点，恢复过程也可以立即重新开始，从而利用可重启恢复的优势。如果备库无法重新启动，则应创建一个全新的备库实例。

如果主库失效，而备库成为新的主库，那么旧主库之后如果重新启动，你必须有一种机制通知它，它已经不再是主库。这有时被称为STONITH（Shoot The Other Node In The Head），它对于避免两个系统都认为自己是主库的情况至关重要，因为那种情况会导致混乱，并最终造成数据丢失。

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

PostgreSQL并不提供用于识别主库故障并通知备库的系统软件。现在已经存在许多这样的工具，并且它们通常能很好地与成功故障转移所需的操作系统设施整合在一起，例如 IP 地址迁移。

一旦故障转移到备库，系统中就只剩下一台服务器在运行。这被称为退化状态。原来的备库现在成为主库，而原来的主库已经停机，并且可能持续停机。要恢复到正常运行状态，就必须重新创建一台备库：要么在原主库恢复后在其上重建，要么在第三台可能是全新的服务器上重建。在大型集簇上，可以使用pg_rewind工具来加快这一过程。一旦完成，就可以认为主库和备库已经交换了角色。有些人会选择使用第三台服务器，在新的备库重建完成之前为新的主库提供备份，但显然这会让系统配置和操作流程更加复杂。

因此，从主库切换到备库可以很快，但重新准备故障转移集簇仍然需要时间。定期在主库与备库之间进行切换是有益的，因为它允许每个系统定期停机维护。这也相当于对故障转移机制进行测试，以确保真正需要它时它能够正常工作。建议编写书面的管理操作规程。

如果你选择了逻辑复制槽同步（见Section 47.2.3），那么在切换到备库之前，建议检查备库上已同步的逻辑槽是否已经为故障转移做好准备。这可以通过执行Section 29.3中描述的步骤来完成。

要触发日志传送备库的故障转移，请运行pg_ctl promote或调用pg_promote()。如果你设置的是仅用于从主库卸载只读查询的报表服务器，而不是用于高可用目的，那么就不需要执行提升。