Orchestrator介绍四-失败/故障检测

目录

Orchestrator-失败/故障检测

传统监控主库方法

Orchestrator检测主库的方法

检测与恢复

故障场景

一些失败场景的详细解释

DeadMaster：（会发生切换）

DeadMasterAndSomeReplicas:（会发生切换）

UnreachableMaster:（不会发生切换）

DeadIntermediateMaster:（会发生切换）

UnreachableMasterWithLaggingReplicas:

LockedSemiSyncMaster

MasterWithTooManySemiSyncReplicas

不会被认为失败/故障的场景

进行失败/故障分析的方法 

---

Orchestrator-失败/故障检测

orchestrator使用整体方法(orc服务节点和复制拓扑中的从副本)探测主库和中间主库的故障。

传统监控主库方法

例如 监控工具会探测主库 ，当无法连接或者查询主库的时候会发出告警。但是这种方法很容易收到网络故障的影响而误报。这种简单的方法通过进行多次间隔为t的测试来减少误报。在某些情况下，这回减少误报的可能性，但在珍珍发生故障时会增加响应时间。

Orchestrator检测主库的方法

Orchestrator 会利用复制拓扑监控主库。 它不仅监控master本身，还利用其从库监控主库的存活。 例如，要诊断主库宕机的场景，orchestrator 必须：

• 连接不上主库
• 能够联系主的副本，并确认它们也看不到master

Orchestrator不按时间对错误进行分类，而是由多个观察者、复制拓扑服务器本身进行分类。 事实上，当master服务器的所有副本都同意它们无法联系主服务器时，复制拓扑实际上就被破坏了，并且故障转移是合理的。

Orchestrator 的整体故障检测方法在生产中非常可靠。

检测与恢复

并不是所有的 检测到故障后都会进行恢复，以下情况不会进行故障恢复：

• 该集群在配置文件中 没有进行 自动故障恢复 的配置
• 管理员账号已经配置在 特定的集群上不进行故障恢复。
• 管理员账号已经全局禁止故障恢复。
• 该集群不久前进行了恢复，发了防止抖动。
• 故障类型被视为不值得被恢复。

在所需的情况下，检测到故障后立即恢复。 在其他情况下，例如恢复受阻，可能会在几分钟后检测到恢复。

检测与恢复无关，检测机制始终启用。 OnFailureDetectionProcesses 挂钩脚本在每次检测时执行，请参阅故障检测配置。

故障场景

• DeadMaster
• DeadMasterAndReplicas
• DeadMasterAndSomeReplicas
• DeadMasterWithoutReplicas
• UnreachableMasterWithLaggingReplicas
• UnreachableMaster
• LockedSemiSyncMaster
• MasterWithTooManySemiSyncReplicas
• AllMasterReplicasNotReplicating
• AllMasterReplicasNotReplicatingOrDead
• DeadCoMaster
• DeadCoMasterAndSomeReplicas
• DeadIntermediateMaster
• DeadIntermediateMasterWithSingleReplicaFailingToConnect
• DeadIntermediateMasterWithSingleReplica
• DeadIntermediateMasterAndSomeReplicas
• DeadIntermediateMasterAndReplicas
• AllIntermediateMasterReplicasFailingToConnectOrDead
• AllIntermediateMasterReplicasNotReplicating
• UnreachableIntermediateMasterWithLaggingReplicas
• UnreachableIntermediateMaster
• BinlogServerFailingToConnectToMaster

一些失败场景的详细解释

DeadMaster：（会发生切换）

1. MySQL主库无法连接
2. 主库所有的从副本复制失败

DeadMasterAndSomeReplicas:（会发生切换）

1. MySQL主库无法连接
2. 部分从副本无法连接
3. 其余从副本复制失败

UnreachableMaster:（不会发生切换）

1. MySQL主库无法连接
2. 存在复制正常的从副本

原因分析：可能由于网络抖动导致orc节点无法连接主库，或者是正在花费时间去找到复制失败的从副本，从而处于这种中间状态。

orc如何处理：orchestrator 将紧急对从副本的重新读取检测，以确定它们是否真的复制正常

DeadIntermediateMaster:（会发生切换）

UnreachableMasterWithLaggingReplicas:

1. 级联复制中的中间主库无法连接
2. 它所有的从副本都复制失败
3. MySQL主库无法连接
4. 所有的非延迟从库（排除sql thread延迟）都有延迟

原因分析：

当主副本“过载”，即连接数过多，客户端会看到 "Too many connections"的提示，但是很久之前已经连接好的从副本连接主副本正常。类似的 ，主库由于元数据锁导致客户端连接被阻塞，而从副本复制正常。然而，由于应用程序无法连接到主服务器，因此不会写入任何实际数据，并且当使用诸如 pt-heartbeat 之类的心跳机制时，我们可以观察到副本上的滞后越来越大。

Orc如何处理这种场景：

Orchestrator 会将所有连接主副本的直接副本重新启动复制来应对这种情况。 这将关闭这些从副本上的旧客户端连接并尝试启动新的连接。 这些现在可能无法连接，导致所有副本上的完全复制失败。  就变为DeadMaster的场景。

LockedSemiSyncMaster

1. MySQL主库开启了半同步复制（rpl_semi_sync_master_enabled=1）
2. 开启了半同步复制的从副本数量小于rpl_semi_sync_master_wait_for_slave_count参数设置的值
3. rpl_semi_sync_master_timeout参数设置的足够大从而master 写锁 也不会退化为异步复制

待补充

MasterWithTooManySemiSyncReplicas

1. MySQL主库开启了半同步复制（rpl_semi_sync_master_enabled=1）
2. 部分开启了半同步复制的从副本已经超过了rpl_semi_sync_master_wait_for_slave_count参数设置的值
3. EnforceExactSemiSyncReplicas 已启用（如果未启用此标志，则不会触发此分析）

待补充 

不会被认为失败/故障的场景

1. 简单的复制异常
2. 复制延迟

进行失败/故障分析的方法 

• 命令行：orchestrator-client -c replication-analysis 或orchestrator -c replication-analysis
• web API  /api/replication-analysis
• 网页：/web/clusters-analysis/页面 ( Clusters-> Failure analysis)。这提供了一个不完整的问题列表，仅突出显示可操作的问题。