MHA Manager日志中SSH连通失败记录常见于slave间互连失败，需逐台执行ssh -o ConnectTimeout=5 mysql@other_host date验证，包括slave→slave和slave→old_master，同时检查sudoers权限、~/.bashrc退出语句及master_ip_failover脚本分支逻辑。
查 MHA Manager 日志里是否真有 SSH 连通失败记录
很多人看到 masterha_manager 启动就退出，第一反应是 MySQL 配置错了。其实 90% 的 case 是 SSH 没通透——不是 manager 连不上 slave，而是 slave 之间互连失败。MHA 切换时会在新主上执行 apply_diff_relay_logs，这就要求新主能免密 ssh 到其他从库拉 relay log。
必须逐台验证，不能只信 masterha_check_ssh 的 “OK”：
- 在每台节点上执行
ssh -o ConnectTimeout=5 mysql@other_host date，包括 slave→slave、slave→old_master（即使 old_master 已宕机，也要能连上 IP） - 确认所有节点的
/etc/sudoers包含mysql ALL=(ALL) NOPASSWD: /usr/bin/env，MHA 内部依赖env获取环境变量 - 检查
~/.bashrc开头有没有exit或return，这类语句会让非交互式 ssh 直接退出，masterha_check_ssh不会报错但实际不可用
看 MySQL 错误日志里 Seconds_Behind_Master 是否为 NULL
masterha_check_repl 报 Seconds_Behind_Master: NULL 不代表复制断了，而是 MHA 读不到延迟值，直接拒绝切换。根本原因是 SQL 线程没跑起来，或 relay log 文件损坏。
在每台从库执行 SHOW SLAVE STATUS\G，重点盯三个字段：
-
Slave_SQL_Running必须是Yes，不是Connecting或空 -
Seconds_Behind_Master必须是数字（如0、12），不能是NULL或空字符串 -
Relay_Log_Space如果为0，说明 I/O 线程也没工作，得先查磁盘空间和relay_log_purge设置
修复顺序固定：STOP SLAVE → RESET SLAVE → START SLAVE；若仍为 NULL，再检查是否手动删过 relay-log.index 或磁盘已满。
确认 master_ip_failover 脚本是否区分 --command=start 和 --command=stop
MHA 默认不管理 VIP，全靠你写的 master_ip_failover 脚本。脚本失效是生产最常踩的坑——它会在一次切换中被调用两次：一次是旧主 shutdown 阶段，一次是新主 start 阶段。如果脚本没做判断，就可能把 VIP 绑到旧主、甚至从新主上删掉。
脚本开头必须加明确分支：
if [ "$1" = "--command=start" ]; then # 这里才执行 ip addr add ... fi
另外注意：
- 别用
ifconfig（已被废弃），改用ip addr add 10.0.1.100/24 dev eth0 - 手动测试：运行
./master_ip_failover --command=start --new_master_host=192.168.1.12，看 IP 是否真绑上 - 网卡名（
eth0）必须在所有节点一致，否则脚本在某台机器上会静默失败
MySQL 8.0 下 MHA 本身是否还能用？先看错误日志里的 binlog 解析报错
MHA 官方早已停止维护，最新版仅支持到 MySQL 5.6。在 8.0 上跑，常见报错包括：Can't exec "mysqlbinlog": No such file or directory、Failed to get binlog position from slave、切换后从库报 ER_NO_DEFAULT_FOR_FIELD。
这些不是配置问题，而是架构不兼容：
-
mysqlbinlog --base64-output=DECODE-ROWS在 8.0 中已被移除 - MHA 无法解析 8.0 的 GTID event 格式，
enforce_gtid_consistency=ON默认开启后，位置计算全乱 - 权限表结构变更（如
mysql.user字段调整），导致CHANGE MASTER TO执行失败
如果你在错误日志里看到类似 Unknown option '--short-form' 或 GTID_PURGED is empty，基本可以确定是版本不兼容。这时候别调参，该换 Orchestrator 就换。
真正卡住排查的，往往不是报错本身，而是日志分散在三处：MHA Manager 日志、MySQL 错误日志（.err）、以及 master_ip_failover 脚本 stdout/stderr —— 它们默认不归集，得人工比对时间戳才能串起完整链路。
