26.3. Failover

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

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

如果主服务器发生故障，并且备用服务器成为新的主服务器，然后旧的主服务器重新启动，则必须具有一种机制，通知旧的主服务器不再是主服务器。这有时被称为 STONITH(在头部射击其他节点)，它是避免两个系统都认为它们是主要系统的情况所必需的，这将导致混乱并最终导致数据丢失。

许多故障转移系统仅使用通过某种心跳机制连接的两个系统(主系统和备用系统)来不断验证两者之间的连通性以及主系统的生存能力。也可以使用第三个系统(称为见证服务器)来防止某些情况下的不适当的故障转移，但是除非经过足够的谨慎和严格的测试，否则额外的复杂性可能不值得。

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

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

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

要触发日志传送备用服务器的故障转移，请运行pg_ctl promote或使用recovery.conf中的trigger_file设置指定的文件名和路径来创建触发文件。如果您打算使用pg_ctl promote进行故障转移，则不需要trigger_file。如果要设置仅用于从主服务器上卸载只读查询(而不是出于高可用性目的)的报表服务器，则无需升级它。