MHA容灾切换性能取决于主从复制状态、SSH可达性、binlog保存能力三根支柱：复制延迟须≤1秒，SSH需秒级响应，binlog抢救必须成功，任一环节异常即导致切换失败或数据丢失。
MHA 的容灾切换性能不是靠“调参数”堆出来的，而是由主从复制状态、SSH 可达性、binlog 保存能力这三根支柱决定的。强行调 secondary_check_script 或 master_ip_failover_script 超时值，只会掩盖底层问题，导致切换失败或数据丢失。
主从复制延迟必须压到 1 秒内，否则 masterha_master_switch 会拒绝切换
MHA 默认要求所有从库 Seconds_Behind_Master ≤ 1，否则不触发自动切换。这不是保守，是防止脑裂和数据回退的硬约束。
- 检查方式：
SHOW SLAVE STATUS\G中的Seconds_Behind_Master字段，不是看Read_Master_Log_Pos和Exec_Master_Log_Pos差值 - 常见卡点：大事务未提交、从库 I/O 线程卡在 relay log 写盘（
Relay_Log_Space持续增长）、主库 binlog 刷盘策略太激进（sync_binlog=1+innodb_flush_log_at_trx_commit=1） - 优化动作：关闭从库
innodb_flush_log_at_trx_commit=2；主库用sync_binlog=1000（牺牲最多 1s 日志）；拆分 > 10MB 的单事务
SSH 连通性必须秒级响应，masterha_check_ssh 失败直接中断整个流程
MHA Manager 依赖 SSH 执行远程命令（如保存 binlog、启停 MySQL、接管 VIP）。哪怕某台从库 SSH 响应超过 3 秒，masterha_manager 就会标记该节点为不可用，可能误判最佳切换目标。
- 典型症状：
Connecting to slave1(192.168.10.102).. ERROR: cannot connect to slave1，但ssh slave1手动能连 - 根因常是：DNS 解析慢（禁用
UseDNS yes）、sshd 服务加载 PAM 模块过多、SELinux 阻断非标准端口 SSH - 实操建议：所有节点统一用 IP 直连（
host配置项填 IP，别填 hostname）；/etc/ssh/sshd_config加UseDNS no+GSSAPIAuthentication no；manager 节点~/.ssh/config设ConnectTimeout 2
binlog 保存失败是隐性性能瓶颈，save_binary_logs 脚本超时等于放弃数据一致性
MHA 在主库宕机后，第一件事就是通过 SSH 执行 save_binary_logs 脚本，尝试从主库磁盘捞出未同步的 binlog。这个步骤默认超时 60 秒 —— 但实际中，如果主库磁盘已损坏或 SSH 断开，它不会等满 60 秒，而是在 SSH session 断开时立即失败，跳过日志抢救，直接走“降级切换”。
- 后果：若唯一收到最新事务的从库没被选上（因延迟略高），且主库 binlog 没抢救成功，就会丢数据
- 关键配置：
master_binlog_dir必须指向主库datadir同盘符下的路径（如/var/lib/mysql），不能是 NFS 或 LVM 快照挂载点 —— 否则脚本读不到实时文件 - 验证方法：手动执行
save_binary_logs --command save --start_file mysql-bin.000001 --start_pos 123 --binlog_dir /var/lib/mysql --output_file /tmp/saved_binlog.binlog，看是否能在 2 秒内完成
真正影响 MHA 切换耗时的，从来不是 ping_interval 或 shutdown_script 这类外围参数。主库挂掉那一刻，你手上只有三样东西：从库的复制位点、SSH 连接通道、主库磁盘上的 binlog 文件。哪一环有毛刺，切换就卡在哪——不是慢，是失败或丢数据。
