数据库高可用方案选型
不同数据库的高可用路线各不相同：MySQL 有主从加编排器、也有基于共识的组复制；PostgreSQL 常用 Patroni 或 repmgr 管理流复制；SQL Server 用 Always On 可用性组；Oracle 有 Data Guard 与 RAC。选型要回答的其实是三个问题：切换判定谁来做、切换时的数据丢失窗口多大、仲裁放在哪里。
基本信息
| 判定者 | 编排器、集群共识或人工决策，决定能否自动切换 |
|---|---|
| 数据窗口 | 异步复制有丢失窗口，同步提交为零丢失但影响写延迟 |
| 仲裁位置 | 决定分区时的集群行为，必须跨故障域 |
| 版本生命周期 | 部分传统工具社区维护趋缓，新环境需评估长期可用性 |
典型使用场景
- 新系统架构评审：在业务 RPO/RTO 约束下比较几种路线
- 存量系统改造：从人工切换升级为自动切换时的方案论证
- 跨机房部署：选择支持跨站点仲裁与复制模式的方案
- 降本评估：对比商业数据库与开源方案在运维复杂度上的差异
- 演练设计：按所选方案的切换机制设计演练场景
常见路线速览
| 数据库 | 常见方案 | 切换粒度 |
|---|---|---|
| MySQL | 主从加编排器（如 Orchestrator） | 实例级，编排器判定 |
| MySQL | 组复制加 Router/Shell | 组内多数派 |
| PostgreSQL | Patroni 或 repmgr 加流复制 | 实例级，可自动提升 |
| SQL Server | Always On 可用性组 | 数据库组级 |
| Oracle | Data Guard 物理备库或 RAC | 库级或实例级 |
选型核对清单
选型核对清单
# 1 目标：RPO 与 RTO 分别是多少，是否有零丢失要求
# 2 切换：自动还是人工？自动切换的判定条件与防脑裂机制是什么
# 3 数据：复制模式（同步/异步/半同步）与切换时的丢失窗口
# 4 仲裁：投票成员数量、分布位置、单点故障后的行为
# 5 运维：备份恢复是否与高可用方案兼容，是否需要额外组件
# 6 生命周期：社区或厂商支持期限，升级路径是否平滑选型的核心问题不是『哪个方案更强』，而是『这套方案在我们团队的运维能力下能否长期稳定运行』：编排器本身也需要高可用，否则它会成为新的单点。