MySQL高可用架构需按RTO/RPO选型：中小规模推荐主从+Orchestrator（半同步），生产环境MGR单主模式需3节点，ProxySQL增强代理层容灾，云服务如RDS/Aurora适合资源有限场景。
MySQL 高可用架构的核心目标是保障数据库服务持续在线、故障时自动恢复、数据不丢失。没有“银弹”方案，需根据业务规模、一致性要求、运维能力选择合适组合。
主从复制 + 哨兵（MHA/Orchestrator）
这是中小规模最常用、落地最成熟的方案。基于原生异步/半同步复制，配合外部故障转移工具实现自动主库切换。
- 推荐使用 半同步复制（rpl_semi_sync_master_enabled），确保至少一个从库落盘后再返回客户端成功，降低主库宕机时的数据丢失风险
- MHA 已停止维护，建议选用 Orchestrator 或 Replication Manager（repmgr）（PostgreSQL 更多，MySQL 可用 Percona 的版本）
- 注意：从库延迟过大时，Orchestrator 默认会拒绝提升，需配置
PreventCrossMaster和SkipIntermediateMaster等策略避免脑裂 - 应用层需支持重连和事务重试，不能依赖连接池自动识别新主库
MySQL Group Replication（MGR）
MySQL 官方提供的基于 Paxos 协议的高可用方案，支持单主/多主模式，内置成员管理与自动故障检测。
- 生产环境强烈建议用 单主模式，避免多主写冲突和死锁放大问题
- 必须部署 至少 3 个节点（奇数），才能容忍 1 节点故障；2 节点无法达成多数派，会整体只读
- 网络抖动易引发节点驱逐，需调优
group_replication_member_expel_timeout（默认 0，建议设为 5–10 秒） - 不兼容 MyISAM、非事务引擎、CREATE TABLE ... SELECT 等语句，上线前务必做 SQL 兼容性扫描
Proxy 层增强：ProxySQL + MGR/主从
ProxySQL 不只是读写分离中间件，更是高可用链路的关键控制点，能屏蔽后端拓扑变化对应用的影响。
- 配置 hostgroup 自动映射：将 writer hostgroup 绑定到当前 PRIMARY 节点，reader 绑定到 SECONDARY，Orchestrator 或 MGR 状态变更时通过 HTTP API 或脚本触发 ProxySQL 重载
- 启用 Query Rules + Delayed Routing，对 select for update、事务内查询强制走主库，避免脏读或不可重复读
- 利用 mysql_server_group_replication_hostgroups 表实现 MGR 状态感知，无需外部脚本轮询
- ProxySQL 本身需双机部署 + keepalived/VIP，避免自身成为单点
云托管方案：RDS 高可用版 / Aurora
如无深度定制需求、团队 DBA 资源有限，直接采用云厂商托管服务是最省心的选择。
- 阿里云 RDS MySQL 高可用版：底层一主一备（物理复制）+ 分离的 HA agent，秒级切换，控制台可查看主备延迟与切换日志
- Aurora 是逻辑重做日志分布式存储架构，计算层与存储层分离，故障切换通常在 10 秒内，且跨 AZ 部署天然防止单点失效
- 注意：RDS 不开放 super 权限，无法装插件、改全局变量；Aurora 兼容性较好但仍有部分语法限制（如不支持 SET GLOBAL innodb_lock_wait_timeout）
- 所有云方案都需开启 备份 + 日志保留 + 跨地域快照，高可用 ≠ 数据安全
选型时先明确 RTO（恢复时间目标）和 RPO（恢复点目标）：若要求 RPO=0，优先考虑 MGR 半同步 + 延迟复制从库；若 RTO
