高可用不是“数据库不宕机”，而是在不可避免的故障发生后，数据损失和恢复时间仍落在业务承诺内。真正的方案必须覆盖复制、故障判断、主库选择、流量切换和数据修复。
一、选组件前先回答六个问题
- 业务允许丢多少数据，RPO 是 0、秒级还是分钟级？
- 从故障到恢复写入，RTO 要求是多少？
- 是否允许短暂停写来换取更强的数据一致性？
- 实例分布在单机房、双可用区还是跨地域？
- 读流量、写流量、数据规模和峰值增长如何？
- 团队能否 7×24 维护复杂的自建组件与故障演练？
二、把高可用拆成五层
| 层次 | 核心问题 | 常见能力 |
|---|---|---|
| 数据复制 | 数据如何到达候选节点 | 异步、半同步、Group Replication |
| 故障探测 | 如何避免一次抖动就误判 | 多点探测、超时、仲裁、人工确认 |
| 主库选举 | 谁最适合成为新主库 | 复制位点、GTID、一致性与故障域 |
| 访问路由 | 应用怎样连接到新主库 | 代理、VIP、DNS、服务发现、连接池刷新 |
| 故障恢复 | 旧主如何重新加入 | 隔离、重建、补数据、回切与复盘 |
三、三类常见路线
路线 A：传统复制 + 编排 + 代理
以 MySQL 复制承担数据同步，Orchestrator 一类工具负责拓扑发现与故障编排，ProxySQL、HAProxy、VIP 或应用侧服务发现承担路由。优点是组件职责清晰、选择灵活；代价是集成、配置与演练都由团队负责。
适合场景
已有成熟 MySQL 运维能力，需要保留异步复制的灵活性，并且能持续维护自动切换与数据修复流程。
路线 B：MySQL Group Replication / InnoDB Cluster
Group Replication 提供组成员管理、故障检测与一致性机制，结合 MySQL Router 等组件形成较完整的官方技术栈。它减少部分外部拼装，但对网络、事务冲突、成员状态与运行限制仍需深入理解。
适合场景
希望采用官方集成方案、节点网络质量稳定，且业务事务模型与组件约束匹配。
路线 C：云托管高可用数据库
由云厂商承担底层实例替换、存储与部分容灾能力。团队仍要理解服务等级、备份恢复、连接切换、跨区行为和监控边界，不能把托管服务等同于“无需设计”。
适合场景
团队更希望聚焦业务与数据治理，能接受云服务边界、成本和平台依赖，并且已验证产品能力满足目标。
四、方案对比不是简单打分
| 维度 | 传统复制 + 编排 | MGR / InnoDB Cluster | 云托管 HA |
|---|---|---|---|
| 灵活性 | 高，可组合 | 中，遵循官方栈 | 受产品边界约束 |
| 运维责任 | 团队承担最多 | 仍需维护集群状态 | 基础设施责任较少 |
| 一致性能力 | 取决于复制与切换设计 | 由组复制机制提供更多能力 | 取决于具体产品承诺 |
| 故障演练 | 必须自建完整流程 | 必须验证成员与路由切换 | 仍需验证应用连接与业务恢复 |
| 适用团队 | 成熟 DBA/SRE 团队 | 愿意遵循官方方案的团队 | 希望降低底层维护成本的团队 |
五、一次安全切换要经过什么
- 确认故障：多维度探测，区分主库故障、网络分区和监控误报。
- 隔离旧主：确保旧主不能继续接受写入，降低双主和脑裂风险。
- 选择新主：比较复制进度、数据一致性、实例健康与所在故障域。
- 补齐并提升：根据目标等待必要数据，完成候选节点角色切换。
- 切换流量：更新代理或服务发现，让应用连接可控地迁移。
- 验证业务：写入、读取、延迟、错误率和关键数据同时校验。
- 处理旧主：重建后再加入，不能未经校验直接恢复写入。
自动切换最大的风险不是“没切”
网络分区下错误提升新主，同时旧主仍对外写入，可能形成双写和数据分叉。因此，可靠的隔离与仲裁通常比追求几秒切换更重要。
六、推荐的选型输出物
- 业务 RPO/RTO 与不可用窗口
- 拓扑图、故障域、数据流和访问流
- 每个组件的职责、探测条件和超时
- 自动切换、人工介入与禁止切换的边界
- 切换 Runbook、回切 Runbook 与数据修复方案
- 季度演练记录和未达标问题清单
七、一句话记忆
先定 RPO/RTO 和一致性，再拆复制、探测、选主、路由与恢复；选能被团队持续维护和演练的最简方案。