关于后端:orchestrator系列二故障检测与恢复

35次阅读

共计 2484 个字符,预计需要花费 7 分钟才能阅读完成。

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 札记,一起交换数据库技术。后盾回复“交换群”可增加技术交换群。欢送感觉读完本文有播种,能够转发给其余敌人,大家一起学习提高!

本文由 mdnice 多平台公布

正文完
 0