Orchestrator 选不出新主库因严格按规则过滤候选者：需 log_bin 开启且 read_only=OFF、延迟≤10秒、半同步配置一致，GTID 模式下须 enforce_gtid_consistency=ON 且 gtid_mode=ON。
Orchestrator 为什么选不出新主库？
常见现象是故障后 orchestrator 日志里反复出现 Cannot find candidate master 或 No valid master candidate found，拓扑卡在“半分裂”状态。根本原因不是选举逻辑坏了，而是它严格按预设规则过滤候选者——不满足条件的从库直接被跳过，哪怕只剩一个。
- 必须开启
log_bin且read_only=OFF（注意：不是ON），否则会被认为“不可升主” - 延迟超过
ReasonableReplicationLag配置值（默认 10 秒）的从库，默认排除 - 如果启用了
SemiSyncEnabled，但候选库没开启rpl_semi_sync_slave_enabled，也会被拒 -
orchestrator不看gtid_executed是否连续，只比对Exec_Master_Log_Pos和Relay_Master_Log_File，所以 GTID 模式下务必确保enforce_gtid_consistency=ON且所有节点gtid_mode=ON
手动触发选举时 raft 模式和 mysql 模式行为差异
两种模式下 orchestrator 的决策依据完全不同：mysql 模式靠心跳 + SQL 线程状态轮询，raft 模式则依赖内嵌 Raft 日志一致性。一旦误切，恢复路径也不同。
-
mysql模式：执行orchestrator -c relocate -a后，它会强制停止原主库的写入（通过SET GLOBAL read_only=ON），再提升指定从库；若中途失败，可能留下read_only=ON但复制未断开的“假只读”状态 -
raft模式：必须先确认当前 Raft leader 在线，否则orchestrator-client会报RAFT: no leader；此时不能硬调relocate，得先用orchestrator -c raft-status查 leader 节点，再 ssh 进去检查/var/lib/orchestrator/raft目录权限和磁盘空间 - 混用风险：同一个集群里不能一部分实例用
raft、一部分用mysql模式，配置项BackendDB必须全局统一，否则拓扑发现会错乱
orchestrator 拓扑发现失败的三个典型路径问题
它不是靠 MySQL 主从关系自动建模，而是依赖主动探测 + 配置白名单。路径写错或权限不对，整个拓扑就“看不见”。最常出问题的是这三处：
-
MySQLTopologyCredentialsConfigFile指向的文件权限必须是0600，且内容里不能有 BOM 头，否则解析失败静默跳过，日志只记Failed to load topology credentials -
DiscoverByShowSlaveHosts默认为true，但若从库没开report_host，就会漏发现；应改false并配合HostnameResolveMethod设为none，改用SHOW SLAVE STATUS解析 - API 接口路径写成
/api/topology是错的——实际是/api/topology/cluster-name，少一级就返回404，前端 UI 显示空白拓扑
如何让 orchestrator 在跨机房场景下不误切
跨机房延迟高、网络抖动多，orchestrator 默认的 3 秒探测间隔和 2 次失败即判宕机会频繁触发误切换。关键不是调大超时，而是分层控制探测粒度。
- 给跨机房链路单独配
InstancePollingIntervalSeconds（比如设为 15），避免和同城实例用同一套心跳节奏 - 禁用
AttemptBecomingMasterOnFailure，这个开关会让它在检测到主库失联时立刻尝试升主，跨机房下极易引发脑裂 - 用
PostUnreachable钩子脚本加一层人工确认：比如往企业微信发告警并要求回复 “YES” 才继续，脚本里调用orchestrator -c relocate -i instance-host:3306必须带完整 host:port
真正难处理的不是选举本身，而是选举前的“状态判定窗口”——orchestrator 只看 SQL 线程是否 running、IO 线程是否 connecting，不验证 binlog 是否真能被消费。网络分区时，一个从库可能显示“复制正常”，但其实 relay log 已停更 5 分钟。这种状态它无法感知。
