mha不是即插即用插件，必须严格按其约束重构主从架构：ssh需全节点（含manager自身）双向免密互通，主库read_only必须为0，所有节点log_slave_updates=on且binlog完整保存，否则masterha_check_repl等检查必然失败。
MHA 不是“用在主从架构中”的可选插件，而是必须严格按其约束重构主从架构才能跑起来的故障切换系统——主从配好了 ≠ MHA 能用。
为什么 mha_check_repl 总报 “SSH is not reachable”
这不是网络连通性问题，而是 MHA Manager 节点对所有 MySQL 节点（包括自己）的 SSH 互信配置不完整。MHA 的检测逻辑会尝试从 Manager 执行 ssh mysql-master date、ssh mysql-slave01 date，甚至 ssh localhost date —— 如果任一失败，mha_check_repl 就直接退出。
- 所有节点（含 Manager 自身）必须生成
ssh-keygen -t rsa，且~/.ssh/id_rsa.pub内容要合并进每个节点的~/.ssh/authorized_keys - Manager 节点上执行
ssh -o StrictHostKeyChecking=no mysql-master true必须静默成功，不能有交互提示 - 如果用了非 root 用户（比如
mha），则sudo -u mha ssh ...也得通，且该用户需有免密sudo权限（mha ALL=(ALL) NOPASSWD: ALL）
masterha_check_status 显示 “PING_OK” 却无法触发 failover
这说明 Manager 看得见主库心跳，但实际已无法执行 SQL 操作——常见于主库卡在锁等待、事务堆积或只读模式未关闭。MHA 默认用 SELECT 1 做 SQL ping，但若主库 read_only=1 或连接池耗尽，查询会 hang 住或拒绝，导致 Manager 误判为“存活但不可写”。
- 检查主库是否意外启用了
read_only=1（SHOW VARIABLES LIKE 'read_only';） - 确认 Manager 配置中的
ping_interval（默认 3 秒）和ping_timeout（默认 3 秒）是否过短；高负载下建议调大到 5~10 秒 - 在 Manager 上手动执行：
mysql -h mysql-master -u mha -pmhapass -e "SELECT 1"，观察是否超时或报错
failover 后从库 Seconds_Behind_Master 一直为 NULL
这是 MHA 切换后典型的 relay log 断裂现象：新主库被提升后，其他从库尝试拉取 binlog 时找不到正确的 Exec_Master_Log_Pos 起始位点，尤其当原主库 binlog 被清空或未保存完整时。
- MHA 切换日志里必须看到类似
Saving binary logs on master mysql-master的成功记录；若出现Could not save binary logs，说明原主库已彻底失联，MHA 只能靠 GTID 或 position 推算，极易出错 - 确保所有节点开启
log_slave_updates=ON，否则从库升主后无法继续向下游提供 binlog - 切完立即在新主库执行
SHOW MASTER STATUS;，再在各从库上CHANGE MASTER TO ... MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy手动对齐（脚本化此步骤比依赖自动修复更可靠）
为什么 masterha_master_switch 手动切换总卡在 “Waiting for the current master to stop…”
它不是发个命令就切，而是先尝试优雅停主库（mysqladmin shutdown），再等 show processlist 中无活跃连接，最后才执行提升。一旦主库上有长事务、未提交 DML 或复制 IO 线程卡死，就会无限等待。
- 执行前先查：
SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND != 'Sleep';，杀掉无关连接 - 确认主库没有正在运行的
mysqldump、pt-table-checksum等工具进程 - 如需强制跳过等待，加参数
--skip_shutdown（但风险是可能丢数据，仅限维护窗口内使用）
真正难的从来不是装上 MHA，而是让它的每一步判断都落在你可控的边界内——比如 binlog 是否真能捞回来、SSH 是否真能穿透所有防火墙规则、GTID 是否全局一致。这些细节不出现在配置文件里，却决定 failover 是秒级恢复还是雪上加霜。
