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。

• 验证方式不是只跑 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] 下的几个参数，尤其在半同步或延迟敏感场景下极易出问题。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 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 的健康门禁，跨不过去，后面全是空谈。