Orchestrator 自身不执行 CHANGE MASTER TO，自动故障切换依赖用户编写的钩子脚本实现；未配置 PostFailoverProcesses 将导致切换后应用无法连接新主库。
Orchestrator 本身不执行 CHANGE MASTER TO，自动故障切换必须靠你写的钩子脚本落地；没配 PostFailoverProcesses，切完主库应用照样连不上。
MySQL 实例必须暴露真实复制状态
Orchestrator 只信 SHOW SLAVE STATUS 和 SELECT @@read_only 的返回值，其他全是干扰项。常见失效点：
-
Slave_IO_Running: No→ Orchestrator 把该从库识别为“孤立实例”，不会纳入候选池 - 主库
log_bin关闭或server_id重复 → 拓扑发现失败，orchestrator-client -c discover返回空 -
report_host是localhost或未配置 → 实例在 Web 界面显示为灰色，无法参与任何切换流程 - GTID 模式下
enforce_gtid_consistency=OFF→ 故障转移时被拒绝，日志报GTID consistency violation
orchestrator.conf.json 里三个字段不能填错
这不是模板填空，是和生产环境强绑定的配置。填错一个，拓扑发现超时、权限拒绝、切换卡死全可能。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
DiscoveryIntervalSeconds: 生产建议设为5，设成30意味着故障最长等半分钟才被发现 -
FailoverType: 必须是"elect"，不是"force"；后者跳过延迟检查，可能把落后 2 小时的从库提为主库 -
PostFailoverProcesses: 必须配置，且至少包含 VIP 漂移、ProxySQL 配置更新、Consul KV 写入三件事；漏掉任意一项，应用层就断连
Pre/PostFailoverProcesses 脚本怎么写才不翻车
这两个钩子是 failover 成败的临界点，不是写个 mysql -e "STOP SLAVE" 就完事。关键约束：
- 所有 MySQL CLI 调用必须加
--connect-timeout=5 --execution-timeout=10，否则挂起会阻塞整个 failover 流程 - 脚本必须基于环境变量分支判断：
ORC_IS_MASTER_FAILURE区分主库宕机还是从库失联，ORC_CANDIDATE_INSTANCE_ALIAS获取目标地址 -
PreFailoverProcesses示例任务：查候选库Seconds_Behind_Master 、确认其 <code>Executed_Gtid_Set包含故障主库全部事务、停 ProxySQL 写组 -
PostFailoverProcesses必须做：SET GLOBAL read_only = OFF（新主）、更新 DNS/VIP、发告警（含ORC_FAILING_INSTANCE和ORC_SUCCESSOR_INSTANCE）
Raft 模式下 Orchestrator 自身不能单点
管理面高可用比数据面还关键——如果 Orchestrator 自己挂了，再健康的 MySQL 也切不动。Raft 集群不是装完就稳：
- 三个节点必须时间同步（
chronyd强制启用），Raft 心跳超时依赖毫秒级时钟一致 -
RaftNodes列表中每个地址必须可被其余节点通过 hostname 解析（skip_name_resolve = OFF是硬要求） - 默认 Raft 端口
3001必须开放，且不能被防火墙或 SELinux 拦截；curl http://node1:3000/api/raft/status返回"state":"Leader"才算真正就绪 - 别用
DatabaselessMode:true，否则拓扑快照无法持久化，重启后要重新 discover，故障窗口直接拉长
最常被忽略的是钩子脚本的超时控制和 Raft 节点间 hostname 解析——这两处出问题，现象都是“看起来在切，但永远卡在 candidate 状态”，日志里反复出现 failover: waiting for candidate to become master，而不是报错。
