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

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

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

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

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

一旦发生了向备库的故障转移，就只剩一台服务器在运行。这被称为退化状态。原备库现在是主库，但原主库已停机，而且可能一直停机。要恢复正常运行，必须重建一个备库——既可以在原主库系统重启后重建，也可以在第三台（可能是新的）系统上重建。完成后，可以说主库和备库交换了角色。有些人选择用第三台服务器为新主库提供备份，直到新的备库重建完成为止，尽管这显然会使系统配置复杂化并增加操作负担。

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

要触发日志传送备库的故障转移，创建一个由recovery.conf中的trigger_file设置指定文件名和路径的触发器文件即可。如果没有给出trigger_file，备库就无法退出恢复并提升为主库。这对于只用于从主库卸载只读查询、而非用于高可用目的的报表服务器等可能很有用。