MHA默认不自动切换，因manager仅监控且需满足硬性前提：复制延迟≤10秒、SSH及状态检查全通过、主库进程确已不可达；误判常见于pid文件残留导致“主库仍存活”假象。
MHA 本身不提供秒级切换的保证，它默认的故障检测+切换耗时通常在 10–30 秒之间；所谓“秒级”，必须靠调优检测频率、关闭非必要检查、配合外部负载均衡（如 SLB）或 VIP 切换脚本才能逼近真实秒级响应。
为什么 masterha_manager 启动后不自动触发故障切换
MHA Manager 默认只做监控，不主动执行 failover，除非满足两个硬性前提：
-
masterha_check_repl检查通过：所有从库Seconds_Behind_Master≤ 10（可调），且复制 IO/SQL 线程均为Yes -
masterha_check_ssh和masterha_check_status均返回成功，且 Manager 配置中master_pid_file或心跳检测确认主库进程已不可达（不是仅 MySQL 连接失败） - 配置项
secondary_check_script若启用，必须全部返回 0，否则会中断 failover 流程
常见误判场景：Can't connect to MySQL server 错误出现后，MHA 仍会尝试 SSH 登录主库并读取 mysql.pid 文件——如果主库 OS 还活着但 mysqld 崩了，而 pid 文件没被清理，MHA 可能误判为主库“还在”，从而跳过切换。
如何把 MHA 故障检测压缩到 3 秒内
关键不是改超时，而是砍掉冗余轮询和校验。以下参数组合实测可在 2–4 秒内完成判定：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 将
ping_interval设为1（单位：秒），同时ping_type=SELECT（避免依赖 TCP 连通性掩盖 MySQL 实际宕机） - 禁用
secondary_check_script，或将其改为单点快速探测（例如仅对一个从库执行mysql -h $slave_ip -e "SELECT 1"） - 设置
shutdown_script为空或轻量脚本（如仅 touch 一个标记文件），避免切换前等待长耗时操作 - 确保
master_ip_failover_script是幂等且无阻塞的——它会在 failover 最后一步执行，若卡住，整个流程就挂住
示例片段（/etc/app1.cnf）：
[server default] ping_interval=1 ping_type=SELECT secondary_check_script="" shutdown_script="" master_ip_failover_script="/usr/local/bin/master_ip_failover"
master_ip_failover 脚本必须处理 super-read-only 场景
MySQL 5.7 开启 super_read_only=ON 后，MHA 提升新主时会因权限不足卡在“apply relay log”阶段——它需要临时关闭该参数才能执行 START SLAVE UNTIL 类操作。
- 脚本中必须显式判断并临时关闭：
mysql -S /tmp/mysql.sock -e "SET GLOBAL super_read_only=OFF;" - 提升完成后，需恢复：
mysql -S /tmp/mysql.sock -e "SET GLOBAL super_read_only=ON;" - 若使用 GTID 复制，还应检查
gtid_executed是否一致，避免跳过事务；脚本里建议加一句SELECT @@global.gtid_executed;日志记录 - 不要依赖
mysqladmin flush-logs——在高并发写入下可能引发 binlog 切换延迟，导致后续从库追不上
SLB 或 VIP 切换不能依赖 MHA 内置逻辑
MHA 的 master_ip_failover 是 shell 脚本，不具备重试、幂等、状态回滚能力。生产环境出问题最多的地方就是这里：
- 阿里云 SLB 后端端口健康检查间隔默认是 5 秒，切完后若立即把旧主加回，可能因 MySQL 还未完全启动而被踢出，造成反复震荡
- 脚本里调用
aliyuncli slb AddBackendServers命令时，必须捕获返回码，失败要 sleep + retry，否则 MHA 认为 failover 成功，但流量实际没切过去 - 切 VIP 时，务必先在新主上
ip addr add，再arping -U刷新网关缓存；否则部分客户端 ARP 缓存未更新，仍发包到旧 IP - 切完后建议用
mysql -h $slb_vip -e "SELECT @@hostname"验证，而不是只看 MHA 日志里的 “New master is elected”
最易被忽略的一点：MHA 切换后不会自动重启应用连接池。哪怕 SLB 已指向新主，老连接仍可能复用旧连接句柄，直到超时或连接池主动探活失败——这会导致“看似切成功，实则部分请求报错”的现象。
