MHA高可用需满足三大硬性门槛：SSH全向免密、server-id全局唯一、manager能SSH拉取宕机主库binlog；必须启用GTID与增强半同步（AFTER_SYNC），所有节点relay_log_purge=0、read_only=1，且系统时间严格同步。
masterha_check_repl 能过就说明主从复制基础已通，但离真正可用的MHA还有至少三处硬性门槛：SSH免密必须全向互通、所有节点 server-id 不能重复、MHA管理节点必须能通过SSH拉取宕机主库的binlog——这三点任一缺失都会导致failover卡在「保存binlog」阶段直接失败。
主从复制必须启用GTID + 增强半同步
MHA本身不强制要求GTID，但MySQL 5.7下若不用GTID，masterha_manager 在识别最新slave时极易误判位置点，尤其在relay log未及时刷新或SQL线程延迟时。增强半同步（rpl_semi_sync_master_enabled=1 + rpl_semi_sync_master_wait_point=AFTER_SYNC）才是关键：
-
AFTER_SYNC模式确保事务提交前binlog已落盘并被至少一个slave ACK，主库崩溃后数据不会丢失 - 必须在所有节点执行
SET GLOBAL relay_log_purge=0，否则MHA的purge_relay_logs脚本无法安全清理中继日志 - 从库
read_only=1是硬性要求，否则MHA检测会报错Slave is not read-only
manager节点必须能SSH访问所有MySQL节点的root用户
这不是“能连上就行”，而是要满足MHA内部调用链路：
-
masterha_check_ssh仅验证连通性，但实际failover中会执行类似ssh root@172.16.40.201 "mysqlbinlog /var/lib/mysql/master-bin.000003 | mysql -uroot -p..."的操作 - 所有MySQL节点的
/root/.my.cnf必须存在且包含正确密码，否则SSH连接后执行mysql命令会卡住 - 若使用非root用户，需在MHA配置中显式指定
ssh_user和ssh_options，且该用户必须有sudo权限执行ifconfig（VIP漂移场景）
master_ip_failover脚本里网卡名和VIP必须手动核对
网上大量教程直接抄 ens33 或 eth0，但CentOS 7+默认是 ens160 或 enp0s3，写错会导致VIP根本无法绑定，而MHA日志只报 Failed to start VIP，不提示具体哪条命令失败：
- 先在每台MySQL节点运行
ip link show确认主用网卡名 -
master_ip_failover中的$ssh_start_vip必须用完整路径，如/sbin/ifconfig ens160:0 192.168.6.235/24 - 脚本开头加
set -x开启调试，failover失败后直接看manager日志末尾的shell执行输出
故障切换后原master重入集群必须手动重置复制位点
MHA完成failover后，原master不会自动变回slave——它仍保留旧的master身份和binlog坐标，强行启动复制会报错 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_log_file='xxx', master_log_pos=xxx; - 切勿用
reset master，否则会清空本地binlog，导致后续二次故障无法恢复
chronyd 或 ntpd），否则 masterha_manager 会因心跳超时反复误判master宕机。 
