数据库容灾方案怎么选？同城双活/两地三中心/多云容灾对比

摘要

数据库容灾方案是保障业务连续性的关键架构决策。本文系统对比同城高可用、同城双活、两地三中心、异地多活四种容灾等级的 RPO/RTO/成本/复杂度，并以 TiDB 为例说明如何通过 Raft 多副本跨机房部署和 Placement Rules 实现灵活的容灾策略。

本文适合谁： 负责数据库容灾架构的 DBA、架构师、IT 负责人。

一、容灾等级划分

数据库容灾方案按覆盖范围分为四个等级，对应不同的故障场景和 RPO/RTO 目标。

二、各方案架构详解

2.1 同城高可用

┌─────────────────────────────────┐
│           同一机房              │
│  TiDB  ←→  TiKV (3 副本)       │
│  PD (3 副本)                     │
└─────────────────────────────────┘

• 架构： 同一机房内 3 个及以上副本
• 防护范围： 节点故障、磁盘故障、网络闪断
• RPO： 0（Raft 多数确认）
• RTO： < 30 秒（自动选举切换）
• 成本增量： 约 1.5 倍（相比单节点）

2.2 同城双活

┌──────────────────┐    ┌──────────────────┐
│   机房 A（主）     │    │   机房 B（灾备）  │
│  TiDB (读写)      │───→│  TiDB (只读)     │
│  TiKV (2 副本)    │←──→│  TiKV (1 副本)   │
│  PD (2 副本)      │    │  PD (1 副本)     │
└──────────────────┘    └──────────────────┘

• 架构： 两个同城机房，数据通过 Raft 协议实时同步
• 防护范围： 整个机房故障
• RPO： 0
• RTO： < 30 秒（Raft 自动切换 Leader）
• 成本增量： 约 2-2.5 倍

2.3 两地三中心

┌────────────┐  ┌────────────┐        ┌────────────┐
│ 机房 A（主） │←→│ 机房 B（同城）│  < 2ms  │机房 C（异地）│
│             │  │             │───────→│ （Learner） │
└────────────┘  └────────────┘        └────────────┘
     同城 < 1ms RTT              异地 10-30ms RTT

• 架构： 同城双活 + 异地灾备（Learner 副本）
• 防护范围： 城市级灾难（地震、火灾等）
• RPO： < 1 秒（异步同步至异地副本）
• RTO： 30 秒 ~ 5 分钟（需切换 DNS/路由）
• 成本增量： 约 3-3.5 倍

2.4 异地多活

┌──────────────┐         ┌──────────────┐
│  北京机房      │←───────→│  上海机房      │
│  TiDB (读写)   │  ≈15ms  │  TiDB (读写)   │
│  TiKV (2 副本) │         │  TiKV (2 副本) │
└──────────────┘         └──────────────┘

• 架构： 两个及以上异地机房同时提供读写服务
• 防护范围： 区域级灾难
• RPO： 0（需应用层处理跨区域一致性）
• RTO： < 30 秒（就近切换）
• 成本增量： 约 4 倍以上
• 复杂度： 最高，需解决跨区域数据一致性、冲突处理等难题

三、TiDB 容灾方案实现

3.1 Raft 多副本跨机房

TiDB 利用 TiKV 的 Raft 协议天然支持跨机房数据同步。每个 Region 的副本分布在不同的机房中，写入经 Raft 多数确认后即可保证同城 RPO = 0。

-- 查看副本分布
SELECT store_id, address, labels FROM information_schema.tikv_store_status;

-- 查看指定表的 Region 分布
SHOW TABLE REGIONS your_table;

3.2 Placement Rules 数据调度

TiDB 提供 Placement Rules 功能，精确控制数据的副本分布策略：

-- 配置 Placement Rule：3 副本，2 个在机房 A，1 个在机房 B
CREATE PLACEMENT POLICY policy_dc_ab PRIMARY_REGION="rack-a"
CONSTRAINTS="[+zone=dc-a] REPLICAS=2, [+zone=dc-b] REPLICAS=1";

-- 将策略应用到表
ALTER TABLE orders PLACEMENT POLICY=policy_dc_ab;

Placement Rules 支持按表、数据库、Namespace 粒度配置，满足不同业务对容灾等级的差异化需求。

3.3 跨机房同步延迟

TiDB 建议同城机房距离控制在 50km 以内，确保 Raft 同步延迟在可控范围。

四、如何选择容灾方案

按业务等级选择容灾方案：

五、FAQ

Q1：两地三中心和同城双活怎么选？

Q2：TiDB 跨机房同步延迟对业务有影响吗？

同城部署（RTT < 2ms）下，TiKV Raft 同步对写入延迟的影响约 1-2ms，大多数业务可接受。跨城部署（RTT > 10ms）时，写入延迟增加 10-30ms，可通过 Learner 模式将跨城同步变为异步，减少对写入性能的影响。

Q3：容灾方案成本增加多少？

Q4：如何做容灾演练？

推荐的容灾演练流程：

1. 准备： 通知相关团队，准备回滚方案
2. 故障模拟： 使用 Chaos Mesh 模拟机房级故障（断网、断电）
3. 切换验证： 观察自动切换行为，验证 RTO 是否达标
4. 业务验证： 检查应用是否能正常读写，数据是否一致
5. 恢复： 恢复故障节点，验证数据同步
6. 总结： 记录演练结果，优化应急预案

建议每季度至少执行一次容灾演练。

六、总结

数据库容灾方案的选择需在业务连续性需求、成本预算和架构复杂度之间取得平衡。TiDB 通过 Raft 多副本、Placement Rules 和 PD 调度，为不同容灾等级提供了灵活而统一的技术实现，帮助企业在合理的成本范围内满足业务连续性要求。

下一步行动

• 咨询 TiDB 容灾方案： 联系 TiDB 架构师获取定制化容灾方案
• 下载容灾白皮书： TiDB 跨区域部署最佳实践白皮书
• 试用 TiDB： 下载 TiDB 并部署高可用集群

相关资源

• TiDB 跨区域部署文档
• TiDB Placement Rules 使用指南
• TiDB 容灾方案最佳实践