MySQL备份解决数据持久性而非服务连续性，高可用需MHA或Orchestrator实现自动故障转移；二者依赖实时复制状态与严格配置，须与备份策略、监控及网络环境协同对齐。
MySQL备份本身不提供高可用，必须配合故障转移工具
备份解决的是数据持久性问题，不是服务连续性。哪怕你每分钟全备一次，主库挂了，应用连不上，还是算宕机。MHA 和 Orchestrator 都是为自动故障转移设计的，它们依赖的是实时复制状态，不是备份文件。
常见错误现象：mysql-bin.000001 日志被 purge 掉导致从库无法追上、Seconds_Behind_Master 持续增长却没告警、MHA 切换后 VIP 没漂移过去、Orchestrator 误判主库为“dead”而发起不必要的切换。
- MHA 要求所有节点时间同步（
ntpdate或chronyd），否则心跳判断失准 - Orchestrator 默认只监控
replication_sql_running和replication_io_running，但忽略SQL_Delay导致延迟主库被误选为新主 - 两者都依赖 SSH 免密或 API 权限，权限配置错一个字符（比如
~/.ssh/config中 Host 别名写错），切换就卡在“connecting to candidate”
MHA 的 failover 触发条件和关键配置项
MHA 不是“一配就灵”，它靠定期执行 masterha_check_repl 检查复制健康度，真正触发切换要满足三个硬条件：主库 SSH 失联 + MySQL 进程不可达 + 至少一个从库 SQL 线程运行中且无严重延迟。
容易踩的坑：masterha_manager 启动后没加 --manager_log，出问题只能看 stderr；candidate_master=1 写在错误的配置段（必须在 [server_x] 下，不能放在 [mysqld] 里）；ping_interval 设成 3 秒但网络抖动频繁，导致误切。
-
secondary_check_script必须配置，例如用另一台机器 ping 主库 IP + telnet 主库 3306，避免单点网络故障引发误判 -
shutdown_script要能真正终止主库 MySQL（如systemctl stop mysqld），不能只是 kill -9，否则可能残留 binlog 未刷盘 -
master_ip_failover_script中修改 VIP 时，务必先ip addr del再add，否则多节点同时操作会冲突
Orchestrator 的拓扑发现与主库选举逻辑
Orchestrator 是基于 HTTP API 的主动发现型工具，它通过定期向每个实例执行 show slave status 和 select @@hostname 构建拓扑图。选举新主时，默认策略是选 Exec_Master_Log_Pos 最大且无 SQL_Delay 的候选者 —— 这个“最大”指的是 relay log 执行位置，不是 binlog 文件序号。
典型问题：orchestrator-client -c topology -d 显示拓扑正常，但 Web UI 上主库图标是灰色，原因是 detect_cluster_alias_query 返回空，Orchestrator 认为该集群未注册；又或者 audit 表里一堆 “Problem: Replication stopped” 却没自动修复，其实是 automatically_recover 设成了 false。
- 必须配置
raft-enabled（>=3.1.0）并部署奇数节点（3 或 5），否则高可用脑裂风险极高 -
prefered-master-regex可以强制指定某类主机名优先当选（如^db-prod-master-），但正则写错会导致全部候选被过滤掉 - Orchestrator 不处理 DNS 变更，如果用域名做
Hostname，VIP 切换后必须手动orchestrator-client -c reload或等下次自动发现
备份如何与 MHA/Orchestrator 协同工作
备份不是旁观者。MHA 切换后，原主库恢复上线时，如果没重放完所有 binlog，直接 change master to 会丢数据；Orchestrator 在 relocate 操作前，会检查目标从库的 Relay_Master_Log_File 是否在当前主库的 show binary logs 列表里 —— 如果你的备份策略清掉了旧 binlog，这个检查就会失败。
最常被忽略的一点：mysqldump --single-transaction 备份期间，MHA 正在做 failover，dump 进程可能卡在 FLUSH TABLES WITH READ LOCK（尤其 MyISAM 表存在时），导致整个切换流程超时中断。
- 物理备份（
percona-xtrabackup）恢复后，必须用xtrabackup_binlog_info中的binlog_file和binlog_pos手动change master to，不能依赖备份时的master.info - 所有备份脚本里加
set global read_only=on前，先查select @@read_only，避免在 MHA 切换中途把新主库锁死 - Orchestrator 的
prevent-cross-replication开启后，禁止跨集群复制，此时跨机房备份恢复的实例无法自动加入原拓扑，得先关掉再discover
真正的难点不在装上 MHA 或 Orchestrator，而在让它们和你的备份节奏、监控粒度、网络分区容忍度对齐。比如 binlog 保留 7 天，但备份恢复平均耗时 8 小时，那这 1 小时的窗口期就是单点故障风险区 —— 没人会提醒你，除非自己画过时序图。
