MHA不能自动切换因五项硬性依赖缺一不可：SSH全向免密、GTID开启、server-id全局唯一、relay_log_purge=0、read_only=1；masterha_check_repl仅验复制连通性，不校验failover全部条件，故通过后仍可能卡在保存binlog或报Slave is not read-only。
MHA不是装上就能自动切换的，它对底层环境有硬性依赖，SSH全向免密、GTID开启、server-id全局唯一、relay_log_purge=0、read_only=1 这五项任一缺失，masterha_manager 启动后大概率卡在「saving dead master’s binary logs」或直接报 Slave is not read-only 错误。
为什么masterha_check_repl通过了，masterha_manager还是起不来？
这个检查只验证复制链路通不通，不校验MHA实际failover所需的全部条件。常见漏掉的点：
-
masterha_check_ssh仅测试连通性，但 failover 中会执行ssh root@192.168.1.10 "mysqlbinlog /var/lib/mysql/mysql-bin.000001 | mysql -uroot -p"—— 所以/root/.my.cnf必须存在且含正确密码，否则卡住无日志 - 所有MySQL节点必须执行
SET GLOBAL relay_log_purge = 0，否则MHA的purge_relay_logs脚本会拒绝清理，导致磁盘爆满或切换失败 - 从库没设
read_only = 1，masterha_check_status直接退出并报错，manager不会启动 - manager节点用非root用户时，配置里必须显式写
ssh_user和带sudo权限的ssh_options，否则VIP漂移命令（如/sbin/ifconfig ens160:0 192.168.4.99/24）会被拒绝
master_ip_failover脚本总报Failed to start VIP，怎么定位？
这不是MHA配置问题，而是脚本执行环境问题。关键动作只有三步，但每步都容易错：
- 先在每台MySQL节点运行
ip link show确认真实网卡名（CentOS 7+ 多为ens160或enp0s3，不是教程里写的eth0） -
$ssh_start_vip命令必须用绝对路径，例如/sbin/ifconfig ens160:0 192.168.4.99/24，不能只写ifconfig - 脚本开头加
set -x，然后手动执行一次：./master_ip_failover --command=start --ssh_user=root --orig_master_host=192.168.1.10 --new_master_host=192.168.1.11，看终端输出哪条shell命令失败
主库宕机后，新主库没收到VIP，但MHA日志显示“failover success”？
这是最危险的假成功。MHA只管选主、改复制关系、调用脚本，**不校验VIP是否真绑定了**。常见原因：
- VIP所在子网的ARP缓存未刷新，客户端仍往旧IP发包；需在新主库执行
arping -c 3 -A -I ens160 192.168.4.99 - 防火墙没关：
systemctl stop firewalld && systemctl disable firewalld，否则ifconfig绑定成功，但ICMP/PING不通，应用连接超时 - 脚本里用了
ifconfig，但某些新版系统默认没装 net-tools，得先yum install net-tools -y
原主库恢复后，为什么不能自动加回集群？
MHA failover 是单向操作，**不会重置原主库的复制状态**。它仍认为自己是master，binlog坐标也停在宕机前。必须人工介入：
- 登录原主库，执行
STOP SLAVE; RESET SLAVE ALL; - 在新主库查
SHOW MASTER STATUS，拿到File和Position - 在原主库执行
CHANGE MASTER TO MASTER_HOST='192.168.1.11', MASTER_USER='repl', MASTER_PASSWORD='replpass', MASTER_LOG_FILE='mysql-bin.000005', MASTER_LOG_POS=12345; - 启动复制：
START SLAVE;，再确认Seconds_Behind_Master = 0 - 最后在manager节点更新MHA配置文件，把原主库加回
candidate_master=1，再重启masterha_manager
真正难的从来不是命令怎么敲，而是每个环节都得严丝合缝：时间同步不准会导致GTID冲突，my.cnf 里少一个 log-slave-updates=ON 就会让从库无法当新主，甚至 /etc/hosts 里主机名解析错一位，masterha_check_ssh 就过不去。这些细节不逐个验证，光靠照抄配置，永远卡在“看起来跑起来了”。
