数据库高可用如何做

数据库高可用（High Availability，HA）的核心目标是：在硬件故障、网络异常、软件 bug、甚至机房级灾难时，仍能保证数据库持续对外提供服务，或尽可能短地中断。

下面从架构方案 → 关键技术 → 落地实践三个层面系统讲清楚。

一、数据库高可用的核心思路

高可用不是“某一招”，而是多层保障：

1. 冗余：一份数据多副本
2. 自动故障转移：主挂了，从自动顶上
3. 数据一致性保障：不丢数据或少丢
4. 容灾能力：跨机房 / 跨地域
5. 可运维性：可监控、可恢复、可演练

二、常见高可用架构方案

1️⃣ 主从复制（最基础）

架构

• 1 主 + N 从
• 主库写，从库读

优点

• 简单
• 读可扩展

缺点

• 主挂需要人工或半自动切换
• 有复制延迟

适用

• 读多写少
• 可接受分钟级切换

2️⃣ 主从 + 自动故障转移（推荐基础方案）

代表

• MySQL：MHA / Orchestrator / Keepalived
• PostgreSQL：Patroni + etcd
• Redis：Sentinel

机制

• 健康检查
• 选主
• VIP / DNS 切换

优点

• 秒级～分钟级恢复
• 成熟稳定

关键点

• 防止“脑裂”
• 切换后数据一致性校验

3️⃣ 多副本强一致（金融级）

方案

• MySQL Group Replication
• PostgreSQL Streaming + Sync Standby
• etcd / Raft 类数据库（TiDB、CockroachDB）

特点

• 多数派提交
• 主挂自动选主
• 数据不丢

适用

• 交易、账务
• 强一致性要求

4️⃣ 共享存储高可用

方案

• 数据库 + 共享磁盘（SAN / 云盘）
• 主挂，备机挂载磁盘

优点

• 零数据丢失

缺点

• 存储是单点
• 云上不推荐

5️⃣ 多活 / 异地多活（高级）

方案

• 单元化
• 分片 + 多写
• 全球化数据库（Spanner、Aurora Global）

挑战

• 冲突处理
• 延迟
• 业务改造大

三、关键技术点（必须重视）

✅ 1. 复制方式

✅ 2. 故障检测

• 心跳
• 超时阈值
• 多节点确认（避免误判）

✅ 3. 脑裂防护

• 仲裁节点（etcd / ZooKeeper）
• fencing（杀掉旧主）
• 云厂商 API 强制下线

✅ 4. 数据一致性校验

• 定期 checksum
• 差异比对
• 切换前校验

✅ 5. 备份与恢复

高可用 ≠ 备份
必须有：

• 全量 + 增量
• 跨地域备份
• 定期恢复演练

四、不同数据库的典型方案

MySQL

• 主从 + Orchestrator
• MGR（Group Replication）
• 云：RDS / PolarDB

PostgreSQL

• Streaming Replication
• Patroni + etcd
• 云：RDS PG / Aurora

Redis

• Sentinel
• Cluster
• 云：Redis Cluster

MongoDB

• Replica Set
• 自动选主

五、落地建议（实战顺序）

1. 先主从 + 自动切换
2. 加监控 + 告警
3. 做故障演练（真的杀主库）
4. 再考虑多副本强一致
5. 最后才做异地多活

六、一句话总结

数据库高可用 = 冗余副本 + 自动选主 + 防脑裂 + 数据校验 + 备份恢复

如果你愿意，可以告诉我：

• 用的什么数据库（MySQL / PG / Redis / 其他）
• 单机房还是多云
• 业务对“丢数据 / 中断时间”的容忍度

我可以直接给你一套可落地的架构图 + 组件选型。