视频：《Orchestrator 管理与实战》
DeadMaster
- 主库访问失败
- 所有主库的副本复制失败
存在一个潜在的恢复过程
"RecoverMasterClusterFilters": [ "db5" ]
停掉db1
2023-09-11 11:48:35
Detected DeadMaster on CS1. Affected replicas: 1
DeadMasterAndSomeReplicas
- 主库访问失败
- 该主库的一些副本也是unreachable的
- 该主库的其余副本处于复制失败状态
存在一个潜在的恢复过程
场景：
"RecoverMasterClusterFilters": [ "db5" ]
停掉db1、db2
日志：
2023-09-11 15:55:31
Detected DeadMasterAndSomeReplicas on CS1. Affected replicas: 2
UnreachableMaster
- 主库访问失败
- 但它有复制状态正常的副本
这并不构成一个恢复过程。但是，为了改善分析，Orchestrator 将发出紧急重新读取复制实例的命令，以确定它们是否真的与主节点保持良好的连接（在这种情况下，可能是因为 Orchestrator 由于网络故障而无法看到它），还是它们实际上正在花时间来确定它们的复制出现问题。
限制IP连接
[root@db1 ~]# iptables -A INPUT -s 192.168.2.103 -j DROP
日志
2023-09-11 16:22:56
Detected UnreachableMaster on CS1. Affected replicas: 2
取消限制
[root@db1 ~]# iptables -D INPUT -s 192.168.2.103 -j DROP
DeadIntermediateMaster
- intermediate master 无法访问
- 该intermediate master所有的副本复制失败
存在一个潜在的恢复过程
"RecoverIntermediateMasterClusterFilters": [
"db5"
],
2023-09-12 14:27:52
Detected DeadIntermediateMasterWithSingleReplicaFailingToConnect on CS1. Affected replicas: 1
UnreachableMasterWithLaggingReplicas
- 主库无法访问
- 所有其直属从库(除延迟从库)都是滞后的(复制延迟)
这种情况可能发生在主节点负载过重的情况下。客户端可能会出现 "连接过多" 的错误，而那些早已连接的复制实例则声称主节点正常。类似地，如果主节点由于某些元数据操作而被锁定，客户端在连接时可能会被阻塞，而复制实例可能声称一切正常。但是，由于应用程序无法连接到主节点，实际上没有数据被写入，当使用像 pt-heartbeat 这样的心跳机制时，我们可以观察到复制实例上的延迟逐渐增加。
Orchestrator 对这种情况的响应是重新启动主节点的所有直接复制实例的复制过程。这将关闭这些复制实例上的旧客户端连接，并尝试建立新的连接。这些新连接现在可能无法成功连接，导致所有复制实例的复制完全失败。接下来，Orchestrator 将分析一个 DeadMaster 情况。
LockedSemiSyncMaster
- 主库启用了半同步(
rpl_semi_sync_master_enabled=1) - 返回ack的从库数量小于
rpl_semi_sync_master_wait_for_slave_count rpl_semi_sync_master_timeout 的值足够高, 主库的写入会被阻塞, 不会退化到异步复制.
2023-09-12 13:46:49
Detected LockedSemiSyncMaster on CS1. Affected replicas: 2
MasterWithTooManySemiSyncReplicas
- 主库启用了半同步(rpl_semi_sync_master_enabled=1)
- 返回ack的从库数量大于rpl_semi_sync_master_wait_for_slave_count
- 启用
EnforceExactSemiSyncReplicas（如果该标志未被启用, 则不会触发该分析）
2023-09-12 13:45:41
Detected MasterWithTooManySemiSyncReplicas on CS1. Affected replicas: 2
