MHA 在 MySQL 5.7 上无法开箱即用实现秒级切换，必须满足复制状态、权限配置、SSH 免密、参数设置等全套前置条件；任一检查（如 masterha_check_repl 或 masterha_check_ssh）失败即卡死流程。
不能直接在 MySQL 5.7 上“开箱即用”MHA 实现秒级切换——它必须依赖一整套前置状态校验和权限/日志配置，任一环节不满足，masterha_check_repl 或 masterha_check_ssh 就会失败，整个流程卡死。
MySQL 主从复制必须满足 MHA 的硬性检查项
MHA 不是靠心跳或网络连通性判断主库是否存活，而是深度读取 SHOW SLAVE STATUS\G 的三项指标：Slave_IO_Running、Slave_SQL_Running、Seconds_Behind_Master。任何一项异常都会被拒绝接管。
-
log_bin和relay_log必须全局启用，且所有节点server_id唯一（不能为 0 或重复） - 从库必须设
read_only=1，但super_read_only=0——否则 MHA 提升时执行RESET SLAVE会报错ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement - MySQL 5.7+ 若未启用 GTID，
enforce_gtid_consistency必须为OFF；若启用了 GTID，则gtid_mode=ON且所有节点一致 -
binlog_format强烈建议设为ROW，避免语句级复制在故障切换后因函数/临时表等导致从库同步中断
SSH 免密必须双向、无交互、无 SELinux 干扰
MHA Manager 要能免密登录所有 MySQL 节点，反过来每个 MySQL 节点也必须能免密登录其他所有节点（含自己），因为 save_binary_logs 脚本内部调用 scp 和远程 mysqlbinlog。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 验证方式不是只跑
ssh-copy-id，而是在 Manager 上逐个执行：ssh root@db251 date、ssh root@db253 date，再登录各从库执行ssh root@db250 date（反向） - 必须在
/root/.ssh/config中显式添加StrictHostKeyChecking no，否则masterha_check_ssh首次连接会卡住等待 yes/no 确认 -
/root/.ssh/authorized_keys权限必须是600，目录权限700；SELinux 若开启，需确认~/.ssh目录上下文为ssh_home_t，否则sshd拒绝认证 - 检查
/etc/ssh/sshd_config：确保PubkeyAuthentication yes和PermitRootLogin yes（或without-password）同时生效
mha.cnf 中三个关键参数决定能否安全切换
很多人填完 IP 和用户就以为配置完成，但真正控制切换行为的是 [server default] 下的几个参数，尤其在半同步或延迟敏感场景下极易出问题。
-
master_binlog_dir必须指向主库真实的 binlog 存放路径（如/var/lib/mysql），否则save_binary_logs找不到日志，切换后丢失最新事务 -
ping_interval默认 3 秒，但若网络抖动频繁，建议设为 1 秒并配合secondary_check_script做多路径探测，避免误切 -
repl_user和repl_password必须是主库上授予REPLICATION SLAVE权限的账号，不能复用root或应用账号；该账号还需有SUPER权限用于RESET MASTER等操作
切换失败最常卡在 masterha_master_switch 的原因
执行 masterha_master_switch --master_state=alive --conf=/etc/masterha/app1.cnf 后卡住，往往不是脚本本身问题，而是底层状态不满足 MHA 的原子性要求。
- 主库虽在线，但
Seconds_Behind_Master为NULL（本质是 IO 线程没起来），常见于relay_log_recovery=1导致从库启动失败 - 从库 relay log 文件损坏或缺失，
masterha_check_repl报Relay log not found，此时需手动CHANGE MASTER TO ... RELAY_LOG_FILE='xxx', RELAY_LOG_POS=yyy - Manager 节点时间与 MySQL 节点偏差 > 1 秒，会导致 binlog 位置比对失败；务必统一使用
chronyd同步时间 - 切换过程中依赖
master_ip_failover脚本管理 VIP，若该脚本 exit code 非 0（比如ip addr add权限不足），整个流程会挂起等待超时
真正影响秒级切换成败的，从来不是 MHA 自身性能，而是你有没有把 masterha_check_repl 和 masterha_check_ssh 这两个检查命令跑通——它们就是 MHA 的健康门禁，跨不过去，后面全是空谈。
