# 27.3.故障转移
如果主服务器失败,则备用服务器应开始故障转移过程。
如果备用服务器失败,则不需要进行故障切换。如果备用服务器可以重新启动,即使是在一段时间后,也可以立即重新启动恢复进程,利用可重启的恢复。如果无法重新启动备用服务器,则应创建一个全新的备用服务器实例。
如果主服务器失败,备用服务器成为新主服务器,然后旧主服务器重新启动,则必须有一种机制,通知旧主服务器不再是主服务器。这有时被称为STONITH(在头部拍摄另一个节点),这是避免两个系统认为它们是主要节点的情况,这将导致混乱,最终导致数据丢失。
许多故障切换系统只使用两个系统,即主系统和备用系统,通过某种心跳机制连接,以持续验证两者之间的连接以及主系统的可行性。还可以使用第三个系统(称为见证服务器)来防止某些不适当故障转移的情况,但如果不经过充分的小心和严格的测试,否则额外的复杂性可能不值得。
PostgreSQL不提供识别主服务器上故障并通知备用数据库服务器所需的系统软件。许多此类工具都存在,并且与成功故障转移所需的操作系统设施(例如IP地址迁移)集成良好。
一旦发生故障切换到备用服务器,则只有一台服务器在运行。这被称为退化状态。前一个备用党现在是主要的,但前一次初选已经结束,可能会继续下去。要恢复正常操作,必须在前主系统出现时或在第三个(可能是新的)系统上重新创建备用服务器。这个pg_重绕实用程序可以用于在大型集群上加快此过程。一旦完成,主角色和备用可以被视为已切换角色。有些人选择使用第三台服务器为新主服务器提供备份,直到重新创建新的备用服务器,尽管这显然会使系统配置和操作过程复杂化。
因此,从主服务器切换到备用服务器可以很快,但需要一些时间重新准备故障转移群集。从主到备用的定期切换是有用的,因为它允许每个系统上的定期停机来进行维护。这还可以作为故障转移机制的测试,以确保它在需要时确实有效。建议采用书面管理程序。
要触发日志传送备用服务器的故障转移,请运行pg_ctl促进
呼叫pg_promote()
,或使用升级触发文件
.如果你打算使用pg_ctl促进
还是打电话pg_promote()
要想彻底失败,升级触发文件
这不是必需的。如果设置的报表服务器仅用于从主服务器卸载只读查询,而不是出于高可用性目的,则无需升级。