数据库引擎怎样容灾

数据库引擎的“容灾”（Disaster Recovery，简称 DR）目标是在机房故障、城市级灾难、人为误删、硬件损坏等极端情况下，依然能保障数据的可恢复性（RPO）和业务连续性（RTO）。

下面从原理 → 常见方案 → 主流引擎实现 → 设计要点四个层面说明。

一、容灾的核心原理

数据库容灾本质上依赖三件事：

1. 数据冗余
   • 同一份数据在多个地方存在
2. 复制机制
   • 实时或准实时把数据变更同步出去
3. 故障切换（Failover）
   • 主库不可用时，快速切换到备用库

关键指标：

• RPO（Recovery Point Objective）：丢多少数据
• RTO（Recovery Time Objective）：恢复要多久

二、常见数据库容灾架构

1. 主从复制（Async / Semi-sync）

• 主库写，从库异步或半同步复制
• 最基础方案
• 优点：简单、成本低
• 缺点：异步可能丢数据

适用：同城容灾、读扩展

2. 多副本一致性（Raft / Paxos）

• 多数派写入才算成功
• 自动选主，强一致
• 典型：TiDB、OceanBase、CockroachDB

适用：金融级强一致

3. 双活 / 多活（Active-Active）

• 多地同时读写
• 数据冲突需解决（分区键、冲突合并）
• 技术难度高

适用：全球化业务

4. 异地灾备（冷 / 温 / 热备）

• 冷备：定期备份，恢复慢
• 温备：日志同步，不对外服务
• 热备：实时同步，可切换

5. 存储级容灾

• 底层存储复制（磁盘 / SAN / 云盘）
• 数据库无感知
• 风险：可能复制“脏数据”

三、主流数据库引擎的容灾方式

MySQL

• 主从复制（binlog）
• MGR（Group Replication，基于 Paxos）
• 中间件：MHA、Orchestrator
• 云：RDS 多可用区

PostgreSQL

• 流复制（Streaming Replication）
• 同步 / 异步
• Patroni + etcd 自动切换
• 逻辑复制（跨版本）

Oracle

• Data Guard（物理 / 逻辑）
• Active Data Guard（只读热备）
• RAC + DG 组合

Redis

• 主从 + Sentinel
• Cluster 分片容灾
• AOF / RDB 持久化

分布式数据库

• TiDB：多副本 + PD 调度
• OceanBase：Paxos + 三地五中心

四、容灾设计的关键点

1. 容灾级别选择

2. 避免“假容灾”

• 备份 ≠ 容灾
• 同步延迟监控必须存在
• 定期真实切换演练

3. 脑裂防护

• 使用仲裁（Quorum）
• 网络分区时只一个主可写

4. 容灾不只是数据库

• 应用、配置、DNS、缓存都要同步规划
• 否则“库起来了，业务起不来”

五、一句话总结

数据库容灾 = 冗余副本 + 可靠复制 + 自动切换 + 定期演练

如果你愿意，我可以：

• 按你用的具体数据库（MySQL / PG / Oracle / 分布式）给方案
• 或按**业务等级（金融 / 电商 / 内部系统）**设计容灾架构图