主从复制与高可用：MHA、Orchestrator 与 PXC 对比

结论：MHA、Orchestrator、PXC 并不是同一层次的三个选项——MHA 和 Orchestrator 解决的是「主从复制架构下如何自动选主切换」，PXC 解决的是「多节点同步复制、几乎不丢数据」。如果你的库还是普通主从，选 Orchestrator；如果你要的是跨节点强一致写入，看 PXC。MHA 已停止维护且不兼容 MySQL 8.0，新项目不该再上。

三者不是同一层方案，先别放在一起比

**结论：MHA 与 Orchestrator 属于「故障切换/拓扑管理」工具，PXC 属于「复制协议本身」的替代品，比较维度完全不同。**

主从复制（一主多从、异步或半同步）是绝大多数业务的基础架构，它的痛点不是写不进去，而是主库挂了以后谁来接、多久接、接完会不会丢数据、切完应用连接怎么指向新主。MHA 和 Orchestrator 都长在这一层。

PXC（Percona XtraDB Cluster）基于 Galera 的写集同步复制，集群里每个节点都是对等的可写节点，没有「主从」概念，它替换掉的是复制协议，而不是在复制之上做切换。

因此真正该问的是两个问题：你的 RPO（允许丢多少数据）是多少？你的写事务有多大、有多频繁？

MHA：经典方案，但已经停止维护

**结论：MHA 是 2010 年代最流行的 MySQL 主从自动切换工具，但最后一个版本 0.58 早已停止更新，不支持 MySQL 8.0，仅建议老系统维护性使用。**

它的工作方式是 Manager 节点加各数据节点的 agent，切换时通过 SSH 连到存活从库，比对并补齐彼此差异的 relay log，选出 relay log 最新的从库提升为新主，再让其他从库重新指向它，最后漂移 VIP。

常用命令是 `masterha_check_repl --conf=/etc/mha/app1.cnf` 做复制健康检查，`masterha_manager --conf=...` 启动守护，在线切换用 `masterha_master_switch --master_state=alive`。

它的几个硬伤：强依赖 SSH 免密，Manager 本身是单点（一般靠 keepalived 兜），配置全靠文件加自定义脚本，GTID 支持有限，最致命的是对 MySQL 8.0 基本不可用——8.0 改掉了复制元数据存储方式与若干默认行为，MHA 的补齐逻辑已经对不上。

Orchestrator：当前自建主从高可用的首选

**结论：Orchestrator 是目前自建 MySQL 主从高可用的事实标准，支持 MySQL 5.6/5.7/8.0，GTID 与非 GTID 环境都能算切主位置。**

它是 Go 写的单二进制服务，后端用一个 MySQL 存拓扑元数据，持续探测各节点复制关系，自带 Web UI 可视化整张拓扑图。故障切换时它会先判断哪台从库数据最新，再执行提升、重指、必要时用 Pseudo-GTID 补齐 relay log。

几个关键配置项值得调：`RecoveryPeriodBlockSeconds` 控制同一集群多久内只允许一次恢复，防止抖动连环切；`FailMasterPromotionIfSQLThreadNotUpToDate` 决定 SQL 线程没追平时是否仍强行提升；`DetectClusterAliasQuery` 把集群名映射成业务可读的名字。手动触发可以是 `orchestrator-client -c failover -i mysql-cluster`。

需要提醒的是：Orchestrator 本身也要高可用。单实例一旦挂了就失去自动切换能力，一般部署两三个实例共用后端库，或者配合 raft 达成共识，避免脑裂。另外它 2021 年之后由社区组织接手维护，选版本时留意社区更新节奏。

PXC：同步多主，解决的是「不丢数据」而不是「自动切主」

**结论：PXC 用同步写集认证替代主从复制，任意节点可写、节点故障不影响提交，但写入性能受最慢节点约束，写无法水平扩展。**

PXC 的关键参数在 `wsrep_cluster_address=gcomm://10.0.0.1,10.0.0.2,10.0.0.3` 这样的集群地址上，状态靠 `SHOW STATUS LIKE 'wsrep_%'` 观察：`wsrep_cluster_size` 是成员数，`wsrep_ready` 表示节点是否可接写，`wsrep_flow_control_paused` 反映因为某个节点跟不上而暂停写入的比例。

它有三个必须提前知道的限制。第一，事务在提交前要在全集群做认证，冲突会直接回滚，业务侧会看到比单机更多的死锁，重试逻辑必须写好。第二，DDL 默认走 TOI（Total Order Isolation），执行期间全集群阻塞，大表加字段会直接卡住业务。第三，大事务是灾难，`wsrep_max_ws_rows`、`wsrep_max_ws_size` 有默认上限，几百万行的批量 UPDATE 会把整个集群拖死。

所以 PXC 适合的是小事务、高频、对数据一致性要求极高的场景，至少部署 3 个节点才能容忍 1 节点故障，且节点数建议为奇数。

选型决策：按业务写负载和 RPO 要求来定

**结论：普通主从 + 可容忍秒级中断，上 Orchestrator；跨机房强一致、绝不接受丢数据，考虑 PXC 或 MySQL 8.0 官方 MGR；仍在跑 MySQL 5.5/5.7 老架构且不愿改造，才考虑继续用 MHA。**

补充两点实践建议。一是无论选哪个，都要在前端配 ProxySQL、MaxScale 或 VIP 做流量路由，切换工具只负责数据层，应用层不感知新主地址才算闭环。二是能上云托管就评估 RDS 高可用版，自建 Orchestrator 或 PXC 的运维成本（尤其 PXC 的扩容与版本升级）往往被低估。

收束一下：先用 RPO 和写事务规模把「主从切换类」和「同步多主类」分开，再在切换类里把 MHA 排除掉，答案基本就落在 Orchestrator 和 PXC 二选一上。