mha主从切换失败报ssh连接失败，实为默认用root远程登录被禁，需手动测试ssh免密登录、显式配置ssh_user、检查密钥权限及relay_log_recovery等。
MySQL 主从切换失败时 MHA 报错 SSH connection failed 怎么查
不是网络不通，而是 MHA 默认用 root 用户连所有节点，但很多环境禁用了 root 的远程 SSH 登录。它不会报“权限拒绝”，而是卡在连接阶段，日志里只显示超时或失败。
- 先手动在 manager 节点上跑：
ssh -o ConnectTimeout=5 -o BatchMode=yes -i /etc/mha/ssh_key user@192.168.1.102，确认能免密登录到每个 MySQL 节点（包括主、从、候选 master） -
MHA配置里必须显式指定user，不能依赖默认值；ssh_user和repl_user是两个独立配置项，别混用 - 检查
/etc/mha/ssh_key权限是否为600，且属主是运行mha_manager的用户（通常是mysql或mha）
主库宕机后 masterha_manager 没触发切换，日志停在 Checking slave status
常见于从库的 relay_log 位置落后太多，或者某台从库 SQL 线程已停止但 Seconds_Behind_Master 显示为 NULL ——MHA 会直接跳过这台，如果剩下可选节点不足，就放弃切换。
- 确保所有从库都开启了
relay_log_recovery=ON，否则 crash 后 relay log 可能损坏，导致MHA拒绝将其作为候选 master - 检查
master_ip_failover_script是否存在且有执行权限；即使不改 VIP，脚本也必须返回 0，否则MHA认为“故障转移失败”而中止 -
ping_interval默认是 3 秒，但若主库只是短暂卡住（比如锁表），MHA可能误判；建议搭配secondary_check_script做双网段探测，避免单点网络抖动引发脑裂
切换后应用连不上新主库：Can't connect to MySQL server on 'old_master_ip'
这不是 MHA 的问题，是客户端没感知 IP 变更。它只负责切换 MySQL 角色和 VIP（如果配了），不改 DNS、不刷新连接池、不通知应用。
- 务必用 VIP（虚拟 IP）做应用连接地址，而不是写死某台物理 IP；VIP 必须绑定在新 master 上，且要禁用
arp_ignore和启用arp_announce，否则局域网内其他机器缓存旧 ARP 表 - 如果不用 VIP，就得靠外部服务（如 Consul + HAProxy）做后端发现，
MHA本身不提供服务注册能力 - 注意：MySQL 8.0+ 默认开启
caching_sha2_password插件，老客户端可能连不上新主；切换前统一设为mysql_native_password，或确保应用驱动支持
MHA 的 masterha_check_repl 一直提示 Health is critical
关键不在复制延迟，而在 GTID 或 binlog 格式不一致。比如主库开了 gtid_mode=ON，但从库是 OFF，MHA 会直接拒绝管理这个集群。
- 所有节点必须统一
binlog_format=ROW，混合模式或 STATEMENT 容易导致MHA解析 position 失败 - GTID 必须全集群开启或全关；如果开 GTID，
enforce_gtid_consistency=ON也得同步打开，否则masterha_check_repl会报错但不说明具体原因 - 检查从库
SHOW SLAVE STATUS\G中的Retrieved_Gtid_Set和Executed_Gtid_Set是否为空，空值意味着复制根本没启起来，MHA不会帮你修复制链路
真正麻烦的是跨版本兼容和半同步插件冲突——比如 MySQL 5.7 的 rpl_semi_sync_master 和 8.0 的 semisync_source 名称不同，MHA 脚本若硬编码旧参数就会静默失效。
