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

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

如果主服务器发生故障，备用服务器成为新的主服务器，然后旧的主服务器重新启动，则必须有一种机制来通知旧的主服务器它不再是主服务器。这有时称为STONITH（射杀另一个节点），这是必要的，以避免两种情况，即两个系统都认为自己是主服务器，这将导致混乱并最终导致数据丢失。

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

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

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

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

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