文章目录
- 第十一章 镜像架构和规划 - 自动故障转移机制详解
- 自动故障转移机制详解
- 代理控制模式
- Primary对失联的反应
- 备份对失联的反应
- 仲裁者控制模式
- 主服务器与备份服务器失去连接
第十一章 镜像架构和规划 - 自动故障转移机制详解
自动故障转移机制详解
本节提供有关故障转移机制的更多详细信息。
镜像对故障转移成员之间或故障转移成员与仲裁器之间失去联系的响应通过使用两种不同的镜像故障转移模式来支持,如下所示:
Agent
控制模式Arbiter
控制模式
代理控制模式
当镜像启动时,故障转移成员开始在代理控制模式下运行。如果仲裁器不可用或未配置仲裁器,它们将保持此模式。在代理控制模式下,故障转移成员对彼此失去联系做出响应,如下所述。
Primary对失联的反应
如果主服务器失去了与活动备份的连接,或者超过了等待它确认接收数据的QoS
超时,主服务器将撤销备份的活动状态并进入故障状态,等待备份确认它不再活动。当主服务器从备份接收到确认信息或故障超时(是QoS
超时的两倍)到期时,主服务器退出故障状态,以主服务器的身份恢复操作。
如果主服务器失去与非活动备份服务器的连接,它将继续作为主服务器运行,不进入故障状态。
备份对失联的反应
如果备份服务器失去了与主服务器的连接,或者超过了等待主服务器消息的QoS
超时时间,备份服务器将尝试联系主服务器的ISCAgent
。如果代理报告主实例仍然作为主实例运行,备份将重新连接。如果代理确认主服务器宕机或已强制主服务器宕机,备份服务器的行为如下:
- 如果备份是活动的,并且代理确认主服务器在故障超时内停机,则备份将接管为主服务器。
- 如果备份未激活,或超过故障超时,则如果代理确认主服务器已关闭,并且可以从代理获取最新的日志数据,则备份将接管。
无论备份是否处于活动状态,备份都不能在代理控制模式下自动接管,除非主服务器本身确认挂起或主服务器的代理确认主服务器宕机(可能是在强制宕机之后),如果主服务器的主机宕机或网络隔离,这两种情况都不会发生。
注意:当其中一个故障转移成员重新启动时,它会尝试联系另一个成员的ISCAgent
,其行为与未激活的备份相同。
仲裁者控制模式
当故障转移成员彼此连接时,两个成员都连接到仲裁程序,并且备份处于活动状态,它们进入仲裁程序控制模式,在这种模式下,故障转移成员根据仲裁程序提供的关于其他故障转移成员的信息对它们之间失去联系作出响应。由于每个故障转移成员通过测试其与其他故障转移成员的连接来响应其仲裁连接的丢失,反之亦然,因此由单个网络事件引起的多个连接丢失将作为单个事件处理。
在仲裁控制模式下,如果任何一个故障转移成员仅失去其仲裁连接,或者备份失去其活动状态,则故障转移成员协调切换到代理控制模式,并响应针对该模式所述的进一步事件。
如果主服务器和备份服务器之间的连接在仲裁控制模式下断开,每个故障转移成员将根据仲裁连接的状态做出响应,如下所述。
主服务器与备份服务器失去连接
如果主服务器失去了与活动备份的连接,或者超过了等待它确认接收数据的QoS
超时时间,并且从仲裁服务器获悉仲裁服务器也失去了与备份的连接,或者超过了等待备份响应的QoS
超时时间,主服务器将继续作为主服务器运行,并切换到代理控制模式。
如果主服务器得知仲裁程序仍然连接到备份程序,它就会进入故障状态,并试图通过仲裁程序与备份程序协调切换到代理程序控制模式。当协调切换完成,或者主服务器得知备份服务器不再连接到仲裁器时,主服务器将作为主服务器返回正常操作。
如果主服务器失去了仲裁连接以及与备份服务器的连接,则主服务器将无限期地保持故障状态,以便备份服务器可以安全地接管。如果发生故障转移,当连接恢复时,主服务器将关闭。
注意:故障超时不适用于仲裁控制模式。