MySQL高可用必须解决主库故障自动接管、零数据丢失、应用无感知三大问题；MGR是内核级强一致集群方案，Orchestrator是外部复制拓扑调度器，二者属不同层级，不可互替。
MySQL高可用不是“配个主从就能用”，而是必须解决三个硬问题：主库挂了谁来接、数据会不会丢、应用连谁。MGR 和 Orchestrator 是两类不同层级的方案——MGR 是内核级一致性保障，Orchestrator 是外部调度器；选错层级，故障时照样要人工介入。
什么时候该用 MGR 而不是 Orchestrator
MGR 本质是 MySQL 实例自己协商状态、自己投票选主，不依赖外部服务。它适合对 RPO=0（零数据丢失）有明确要求的场景，比如支付、账务类系统。
- 必须满足：MySQL ≥ 5.7.17，所有节点开启
gtid_mode=ON、enforce_gtid_consistency=ON - 网络必须稳定：MGR 使用专用端口（如
33061）做组通信，防火墙漏放一个端口，节点就进不了集群 - 不能混用引擎：MyISAM、MEMORY、CREATE TABLE ... SELECT 等语句会直接被拒绝，上线前得跑 SQL 兼容性扫描
- 单主模式是生产默认选择；多主模式需确保每张表都有显式主键，且禁用外键级联
Orchestrator 不是“装上就自动高可用”
Orchestrator 只负责观测和调度，它本身不参与数据同步。如果底层还是异步复制，延迟大、半同步没开、从库 IO/SQL 线程已停，Orchestrator 就会卡在“检测中”或直接拒绝 failover。
- 必须配半同步：启用
rpl_semi_sync_master_enabled，否则主库崩溃时可能丢事务 - 延迟容忍要设合理：默认
PreventCrossMaster为 true，当从库延迟 > 30 秒，Orchestrator 会拒绝提升——这不是 bug，是防脑裂的保护 - 后端存储别用单点 MySQL：生产环境务必走 Raft 模式，至少 3 个 Orchestrator 实例共用一个 Raft 日志，否则 Orchestrator 自身挂了，整个 HA 链路就断了
- 它不改应用连接逻辑：应用仍需重连新主库，或者配合 ProxySQL 做 hostgroup 动态映射
ProxySQL 是 MGR 或 Orchestrator 的必要搭档
单独部署 MGR 或 Orchestrator，应用层仍然感知后端变化。ProxySQL 才是让“切换对业务透明”的关键一环。
- 写请求必须路由到
writerhostgroup，这个 group 要绑定当前 PRIMARY 节点（MGR）或 master（Orchestrator） - 读请求走
readerhostgroup，但要注意：SELECT ... FOR UPDATE必须强制走 writer，否则脏读风险极高 - MGR 场景下，直接查
mysql_server_group_replication_hostgroups表就能拿到角色状态，不用轮询 HTTP API - ProxySQL 自身必须高可用：双机 + keepalived/VIP，否则它成了新的单点
真正容易被忽略的是时间同步和权限粒度。所有 MGR 节点的 chronyd 必须指向同一 NTP 源，误差超 1 秒就可能触发误驱逐；Orchestrator 连接后端 MySQL 的账号，不能只给 SELECT 权限，还得有 REPLICATION_SLAVE_ADMIN 和 CONNECTION_ADMIN，否则发现不了复制中断的真实原因。
