根本原因是ssh免密未通透，mha要求所有mysql节点两两互通（包括从库间、从库到旧主），需逐台执行ssh -o connecttimeout=5 mysql@other_host date验证；masterha_check_ssh显示ok不等于可用，还需检查sudo nopasswd权限及~/.bashrc无exit语句。
masterha_manager启动就退出，怎么排查？
根本原因几乎全是SSH免密没通透——MHA不是只要求从管理机连各节点，而是要求所有MySQL节点（包括从库之间）两两SSH免密互通。比如rep1要能ssh rep2秒回，否则切换时拉取relay log会失败。
- 逐台执行
ssh -o ConnectTimeout=5 mysql@other_host date，不能只测manager→slave，必须测slave→slave、slave→old master（即使宕机也要能连上） -
masterha_check_ssh输出“OK”不等于可用：它不校验sudo NOPASSWD:/usr/bin/env权限，也不检查~/.bashrc里有没有exit语句 - 非root用户（如mysql）运行时，确认每台机器的
/etc/sudoers中包含：mysql ALL=(ALL) NOPASSWD: /usr/bin/env
masterha_check_repl报Seconds_Behind_Master: NULL怎么办？
这不是复制断了，是MHA读不到延迟值，直接拒绝切换。核心原因是SQL线程没跑起来，或relay log损坏。
- 在每台从库执行
SHOW SLAVE STATUS\G，重点看Slave_SQL_Running是否为Yes，Seconds_Behind_Master是否为数字（不是NULL或空字符串） -
Seconds_Behind_Master为NULL常见于：START SLAVE UNTIL后未重启、磁盘满导致relay log写失败、手动删过relay-log.index文件 - 修复方法：先
STOP SLAVE，再RESET SLAVE，最后START SLAVE；若仍为NULL，检查Relay_Log_Space是否为0，为0说明I/O线程也没工作
切换后应用连不上新主，VIP没漂移？查master_ip_failover
MHA默认不管IP，全靠你写的master_ip_failover脚本。脚本失效是生产环境最常踩的坑。
- 脚本开头必须区分命令类型：
if [ "$1" = "--command=start" ]; then才执行绑定VIP；--command=stop阶段只做清理 - 别用
ifconfig（已废弃），改用ip addr add 192.168.4.50/24 dev eth0，并确保所有节点网卡名一致（别有的叫ens33，有的叫eth0） - 手动测试脚本：
./master_ip_failover --command=start --ssh_user=root --orig_master_host=192.168.4.80 --new_master_host=192.168.4.90，看VIP是否真出现在新主上
为什么选中的新主数据不最新？选举逻辑被绕过了
MHA默认按Relay_Master_Log_File和Exec_Master_Log_Pos选主，但如果你没配candidate_master=1或no_master=1，它可能跳过延迟最小的节点。
- 在MHA配置文件中，给优先候选的从库加
candidate_master=1，强制参与选举；给只读从库加no_master=1，排除它 - 别依赖“启动时间早”或“IP顺序”，MHA根本不看这些；它只比对
SHOW MASTER STATUS里的File和Position - GTID模式下，MHA会用
Executed_Gtid_Set比对，但前提是所有节点gtid_mode=ON且enforce_gtid_consistency=ON，缺一不可
read_only=1 + super_read_only=1双保险，且切换脚本里必须包含对旧主的强制只读设置。
