MHA在MySQL 5.7上可用但默认配置必败，核心卡点是SSH全向免密、manager能SSH拉取宕机主库binlog、GTID+增强半同步（AFTER_SYNC）三者缺一不可；另需relay_log_purge=0、read_only=1、网卡名与VIP脚本路径精准匹配，原master恢复须手动重置复制。
MHA在MySQL 5.7上能用，但默认配置几乎必然失败——核心卡点不在复制本身，而在SSH、binlog访问权限和GTID语义一致性这三处。
masterha_check_repl通过 ≠ MHA能正常failover
很多用户跑通masterha_check_repl就以为万事大吉，结果一触发failover直接卡死在「Saving master binlog」阶段。这是因为该命令只校验SQL线程是否运行、IO线程是否连接、Seconds_Behind_Master是否为0，但完全不检查：
- MHA Manager节点能否用
ssh root@master登录后执行mysqlbinlog /var/lib/mysql/master-bin.000003（路径、权限、SELinux限制都可能拦住） - 所有节点的
/root/.my.cnf是否真实存在且含正确密码（否则mysql -uroot -e "..."会交互式卡住） - 主库崩溃时，
save_binary_logs脚本依赖mysqlbinlog --stop-never持续拉取，而MySQL 5.7默认log_bin_trust_function_creators=OFF会导致该脚本报错退出
GTID + AFTER_SYNC半同步是MySQL 5.7下MHA的硬性组合
不用GTID，MHA在识别“最新slave”时会退化为比对Relay_Master_Log_File和Exec_Master_Log_Pos，但MySQL 5.7中relay log刷新有延迟、SQL线程可能暂停，极易误判。必须启用：
-
gtid_mode=ON且enforce_gtid_consistency=ON（my.cnf中两行都得写） -
rpl_semi_sync_master_enabled=1+rpl_semi_sync_master_wait_point=AFTER_SYNC（不是AFTER_COMMIT） - 所有节点执行
SET GLOBAL relay_log_purge=0（否则purge_relay_logs脚本无法安全清理） - 从库必须
SET GLOBAL read_only=1（MHA检测脚本会直接拒绝启动）
master_ip_failover脚本里最常踩的三个坑
网上大量教程抄来的脚本，在CentOS 7+上90%会失败，原因全在细节：
- 网卡名写死
eth0或ens33：实际应先在每台MySQL节点运行ip link show确认主用接口（常见为ens160或enp0s3） -
$ssh_start_vip命令没用绝对路径：ifconfig ens160:0 192.168.6.235/24必须写成/sbin/ifconfig ens160:0 192.168.6.235/24 - 脚本开头没加
set -x：failover失败时manager日志只显示Failed to start VIP，根本看不到哪条shell命令出错；加了之后末尾会打印完整执行链路
原master恢复后不能自动回归集群
MHA failover完成后，原master仍保留旧的master_host和Executed_Gtid_Set，强行START SLAVE会报错Got fatal error 1236 from master。必须手动重置：
- 在新master上执行
SHOW MASTER STATUS拿到File和Position - 在原master上执行
STOP SLAVE; RESET SLAVE ALL; - 再执行
CHANGE MASTER TO MASTER_HOST='new_master_ip', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION=1;（注意是MASTER_AUTO_POSITION=1，不是position模式） - 最后
START SLAVE;并检查Seconds_Behind_Master
这个过程没有自动化脚本兜底，漏掉任何一步，原master就会永久离线。
