MHA要求至少三台服务器，因为其故障切换需同时存在master、数据最新的slave（用于提升）和额外slave（验证一致性、补全relay log、防脑裂）；双节点无法交叉验证复制状态、安全拉取宕机主库binlog，导致masterha_manager启动即退出或切换时数据丢失。
不能在双节点服务器上搭建真正可用的 MHA 故障切换环境。
为什么 MHA 要求至少三台服务器
MHA 的故障切换逻辑依赖三个角色同时存在：一个 master、至少一个数据最新的 slave（用于提升为新 master）、以及一个额外的 slave（用于验证数据一致性、补全 relay log、避免脑裂）。双节点只能构成一主一从，一旦主库宕机：
- MHA 无法判断从库是否真的“最新”——没有第三方节点交叉验证
Seconds_Behind_Master和 GTID/Executed_Gtid_Set - 宕机主库的 binlog 无法被安全拉取（需要 SSH 连入原主，但双节点时管理节点往往复用从库，权限和网络路径受限）
-
masterha_manager进程启动后会立即退出，日志只显示Started automated failover.，因为masterha_check_repl检查失败（返回Replication health is not OK）
双节点强行部署 MHA 会出现哪些典型错误
即使跳过校验硬起 masterha_manager，运行时仍会暴露底层缺陷：
-
masterha_check_repl --conf=/etc/mha/app1.cnf报错：Can't get master's binary log position或Seconds_Behind_Master: NULL—— 因为从库 SQL 线程可能未 RUNNING，或 MHA 无法通过第二节点确认复制位点有效性 - 触发切换时，
save_binary_logs在原主失败（SSH 不通或磁盘不可读），导致新主缺失最后几秒事务，MHA 日志中出现Failed to save binary logs -
apply_diff_relay_logs无差异源可比，跳过关键补偿步骤，多个从库间 GTID gap 扩大，后续CHANGE MASTER TO失败
如果只有两台物理机，替代方案怎么选
不是“把 MHA 塞进双节点”，而是换用适配双节点语义的工具：
- 用
Keepalived+MySQL 主从：配置 VIP 漂移，但必须配合半同步（rpl_semi_sync_master_enabled=ON）和after_sync模式，降低丢数据风险；缺点是不感知 MySQL 内部状态（如 SQL 线程卡死） - 用
Orchestrator：支持双节点在线切换（orchestrator -c relocate），能检测复制线程、自动修复relay log，且开源免费；需自行处理 VIP 或 DNS 切换 - 放弃自动切换，改用
masterha_master_switch --master_state=alive手动切：仅限维护窗口，要求 DBA 提前确认从库延迟 ≤ 1s、SQL 线程 RUNNING、GTID 一致
真正的高可用不是靠节点数量堆砌，而是让每个组件各司其职。MHA 的设计前提就是“有冗余验证能力”，少一台，它就不再是 MHA，而是一个随时可能静默失败的脚本集合。
