Orchestrator实现了自动Failover，现在来看看自动Failover的大致流程是怎么样的。
1、故障检测（Failure detection）
orchestrator使用整体性方法来检测主节点和中间主节点的故障。
在原始的检测方法中，监控工具会探测主节点，并在无法联系或查询主服务器时发出警报。这种方法容易受到网络故障引起的误报的影响。为了减少误报的几率，简单方法通过以t长时间间隔运行n个测试来缓解这个问题。这在某些情况下减少了误报的几率，但也增加了在真正故障事件发生时的响应时间。
orchestrator利用了复制拓扑。它不仅观察master server本身，还观察其副本。例如，为了诊断一个主节点失效的情况，orchestrator必须同时满足以下两个条件：
无法连接主节点
能够连接到主节点的副本，并确认它们也无法看到主节点
orchestrator不是按时间来排查错误，而是通过多个观察者，即复制拓扑中的服务器。实际上，当一个主节点的所有副本都一致认为它们无法联系到主节点时，复制拓扑实际上已经出现故障，此时进行故障转移是合理的。
orchestrator的整体性故障检测方法在生产环境中被认为非常可靠。
2、检测和恢复（Detection and recovery）
检测并不总是导致恢复。有一些情况下不希望进行恢复：
集群没有被列为自动故障转移的候选项；
管理员指示不应在特定服务器上进行恢复；
管理员全局禁用了恢复操作；
在之前的故障转移完成后不久，进行了反复操作；
故障类型被认为不值得进行恢复；
在期望的情况下，恢复会立即跟随检测。在其他情况下，例如被阻止的恢复，恢复可能在检测后的几分钟内进行。
检测是独立于恢复的，并且始终处于启用状态。根据检测执行OnFailureDetectionProcesses钩子函数，具体配置看下文故障检相关测配置。
3、故障检测相关配置
故障检测的配置：
{
"FailureDetectionPeriodBlockMinutes": 60,
}
组织发送时间，orchestrator每秒检测一次。
hooks：
{
"OnFailureDetectionProcesses": [
"echo 'Detected {failureType} on {failureCluster}. Affected replicas: {countReplicas}' >> /tmp/recovery.log" ],
}
MySQL 侧设置：
set global slave_net_timeout = 4
在从库和主库之间设置一个较短（2秒）的心跳间隔，使从库能够快速识别故障。如果没有进行此设置，某些情况可能需要长达一分钟才能检测到故障。
CHANGE MASTER TO MASTER_CONNECT_RETRY=1, MASTER_RETRY_COUNT=86400
在复制失败的情况下，使从库每秒尝试重新连接（默认为60秒）。对于短暂的网络问题，此设置尝试快速恢复复制，如果成功，将避免由协调器执行的一般故障/恢复操作。
故障检测场景
以下是潜在故障列表：
- DeadMaster 主节点故障
- DeadMasterAndReplicas 主节点和副本节点故障
- DeadMasterAndSomeReplicas 主节点和部分副本节点故障
- DeadMasterWithoutReplicas 主节点没有副本节点
- UnreachableMasterWithLaggingReplicas 无法访问的主节点且存在滞后的副本节点
- UnreachableMaster 无法访问的主节点
- LockedSemiSyncMaster 被锁定的半同步主节点
- MasterWithTooManySemiSyncReplicas 主节点具有过多的半同步副本
- AllMasterReplicasNotReplicating 所有主节点副本均未进行复制
- AllMasterReplicasNotReplicatingOrDead 所有主节点副本未进行复制或停止工作
- DeadCoMaster 协同主节点故障
- DeadCoMasterAndSomeReplicas 协同主节点和部分副本节点故障
- DeadIntermediateMaster 中间主节点故障
- DeadIntermediateMasterWithSingleReplicaFailingToConnect 中间主节点故障且单个副本无法连接
- DeadIntermediateMasterWithSingleReplica 中间主节点故障且只有一个副本节点
- DeadIntermediateMasterAndSomeReplicas 中间主节点和部分副本节点故障
- DeadIntermediateMasterAndReplicas 中间主节点和副本节点故障
- AllIntermediateMasterReplicasFailingToConnectOrDead 所有中间主节点副本无法连接或停止工作
- AllIntermediateMasterReplicasNotReplicating 所有中间主节点副本未进行复制
- UnreachableIntermediateMasterWithLaggingReplicas 无法访问的中间主节点且存在滞后的副本节点
- UnreachableIntermediateMaster 无法访问的中间主节点
- BinlogServerFailingToConnectToMaster Binlog服务器无法连接到主节点
4 拓扑恢复
拓扑恢复
orchestrator 能够从一系列故障场景中进行恢复。特别是，它可以从主服务器或中间主服务器的故障中恢复。
自动和手动恢复
orchestrator 支持以下恢复方式：
- 自动恢复（在意外故障时采取行动）。
- 优雅、计划的主库提升。
- 手动恢复。
- 手动、强制/紧急切换。
欲知后事如何，且听下回分解。
欢迎关注公众号：DBA札记，一起交流数据库技术。后台回复“交流群”可添加技术交流群。欢迎觉得读完本文有收获，可以转发给其他朋友，大家一起学习进步！