MHA不支持真正无缝在线切换，其masterha_master_switch仅提供计划内手动切换，仍需短暂阻塞写入（0.5–2秒）、应用重连及人工配置更新，本质是故障恢复工具而非平滑运维方案。

MHA 本身不支持“无缝在线切换”——它只做故障转移，不支持主动、无中断的主库迁移。 所谓“在线切换”在 MHA 场景中实际是 masterha_master_switch 手动触发的计划内切换，仍会短暂中断写入、需应用重连，且必须满足严格前提，否则容易丢数据或复制断裂。

为什么 masterha_master_switch 不等于“无缝”

MHA 的设计目标是故障恢复，不是平滑运维。即使使用 --master_state=alive 参数执行计划切换，它仍会：

• 强制停止原主库的写入（通过 FLUSH TABLES WITH READ LOCK 或类似机制）
• 等待所有从库追上 relay log，期间新写入被阻塞
• 提升目标从库后，需手动或脚本更新应用连接池配置（VIP 漂移需额外配合 Keepalived）
• 原主库恢复后默认不会自动降级为从库，必须人工执行 CHANGE MASTER TO 并校验 GTID/position

masterha_master_switch 的正确调用条件

想让计划切换尽可能安全、低影响，必须提前确认以下五点：

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

• 所有从库 Seconds_Behind_Master = 0，且 Slave_SQL_Running = Yes、Slave_IO_Running = Yes
• 主库开启 gtid_mode = ON 且所有节点 enforce_gtid_consistency = ON（避免 position 错位）
• 已配置半同步复制（rpl_semi_sync_master_enabled = 1），至少一个从库确认收到 binlog
• app1.cnf 中每个节点的 candidate_master = 1 和 no_master = 1 设置准确，防止误选
• 切换前确保 masterha_check_repl 和 masterha_check_ssh 全部通过，尤其检查 repl 用户权限是否包含 SUPER（用于 RESET SLAVE）

切换命令与关键参数避坑

执行时务必带明确参数，避免默认行为引发意外：

• 用 --conf=/etc/app1.cnf 显式指定配置，不要依赖环境变量
• 必须加 --master_state=alive，否则 MHA 当作宕机处理，会尝试从原主拉 binlog（此时主库其实还活着，可能失败或冲突）
• 指定目标候选：加 --new_master_host=192.168.1.24，否则 MHA 按 relay log 位置自动选，未必是你想要的那台
• 加 --interactive=0 关闭交互提示，适合脚本调用；但首次操作建议先去掉，看清楚每步确认项
• 切忌在从库延迟 > 5 秒时强切，apply_diff_relay_logs 可能因 gap 过大失败，导致新主缺失部分事务

切换后最易忽略的三件事

很多人以为 masterha_master_switch 返回 success 就结束了，其实关键动作在后面：

• 原主库上的 read_only = ON 不会自动关闭，必须手动设为 OFF，再执行 CHANGE MASTER TO ... MASTER_AUTO_POSITION=1 接入新主
• 所有应用连接池里的数据库 URL 若硬编码 IP，必须立刻刷新；用 VIP 的话，要确认 Keepalived 已完成漂移且 ARP 刷新（arping -U -I eth0 $VIP）
• SHOW MASTER STATUS 在新主上查出的 Executed_Gtid_Set 要和原主最后的 Retrieved_Gtid_Set 对齐，否则后续再切回可能跳过事务