国产数据库“同城两中心”容灾方案对比，TiDB 表现优秀

2024-02-23
北京
本文字数：4474 字
阅读完需：约 15 分钟

作者：数据源的 TiDB 学习之路原文来源：https://tidb.net/blog/af773cb8

容灾系统是核心业务必不可少的可用性保障措施，当前主流的国产分布式数据库均支持了多种容灾部署模式，如同城两中心、两地三中心、三地五中心等。本文就几款主流的国产分布式数据库在同城两中心容灾方案上做一个整理与总结，所有内容均基于网上现有的公开资料。

一． TiDB 同城两中心方案

方案一：DR Auto-Sync

TiDB 针对核心业务系统同城两中心的灾备方案有一个专属的名称叫自适应同步模式(Data Replication Auto Synchronous)，简称 DR Auto-Sync。据了解，年前杭州银行上线的核心业务系统就是采用 DR Auto-Sync 实现同城两中心的容灾部署。

DR Auto-Sync 的部署架构推荐集群采用 6 副本模式，其中主中心放 3 个副本（均参与投票），同城中心放 2 个副本（参与投票）和 1 个副本（不参与投票）。我们把参与投票的副本叫 Voter，不参与投票的副本叫 Learner。

如上图所示，主中心的 3 个副本和同城中心的 2 个副本均为 Voter，这 5 个副本构成多数派提交，5 副本中的 3 副本提交成功即返回。为了保证主中心的业务性能较好，通常使用 TiDB 的 Placement Rules 功能将 Leader 副本固定在主中心。正常情况下，由于主中心的 3 个副本在本地机房，网络延迟比同城中心的 2 个副本要低。按照多数派提交原则，主中心的 3 个副本会优先提交，而同城的 2 副本则会存在同步延迟，这意味着主中心和同城中心无法保证 RPO=0。为了解决主中心和同城中心 RPO=0 的问题，TiDB 在多数派提交的基础上增加了分组（Group）的概念。如下图所示，1/2/3 代表主中心的 3 个副本，4/5 代表同城中心的 2 个副本，将 1/2/3 标记为 Group1 并将 4/5 标记为 Group2。当事务提交时，除了要满足多数派提交的要求，还需要判断每个 Group 中至少有一个副本提交，这样就可以保证 RPO=0 的要求。

除了可以保证同城两中心的 RPO=0，DR Auto-Sync 还定义了三种状态来控制和标示集群的同步状态，集群的复制模式可以在三种状态之间自适应切换，这也是 Auto-Sync 的名称由来。三种状态分别为：

sync。同步复制模式，此模式下同城中心至少有一个副本与主中心保持同步状态，可以保证 RPO=0。
async。异步复制模式，此时不保证同城中心与主中心是同步状态。当同城中心故障或两个中心出现网络问题并超时后，为了保证主中心的业务连续性，会自动切换到这个模式。
sync-over。恢复同步，此时不保证同城中心与主中心完全同步。它实际上属于一个中间状态，当同城中心故障恢复后会从 async 切换到 sync-over 状态，最后恢复到 sync 状态。

对比 Oracle 的三种容灾模式——最大保护模式、最大可用模式以及最大性能模式，可以看出，TiDB 的 DR Auto-Sync 接近于 Oracle 的最大可用模式，它是一种在正常情况下保证 RPO=0 而在异常情况下保证主中心最大可用的模式。

再回到上述的架构中说说 Learner 副本，这个副本不参与投票，只是被动的接受 Leader 的日志，那么它的作用是啥呢？首先假设没有这个 Learner 副本，即集群变成 5 副本（主中心 3 副本 + 同城 2 副本），当主中心发现故障后集群只剩下 2 个副本，2 副本是无法构成多数派提交的，所以必须得再增加一个副本重新构成多数派提交。其次如果这个副本是 Voter 角色的话那么集群就变成 6 个 Voter 副本，也不满足多数派提交原则，所以它必须是 Learner 角色。简单总结一下，Learner 副本是必须的，它是解决主中心故障后同城中心重新构成多数派协议并单独对外提供服务的前提。

DR Auto-Sync 的灾难恢复及解决方法为：

如果主中心故障，丢失大多数 Voter 副本，但同城中心有完整数据。此时需要人工介入，通过专业工具恢复。
如果同城中心故障，丢失少数 Voter 副本，此时自动切换为 async 异步复制模式。

方案二：TiCDC

TiCDC 是一款 TiDB 增量数据同步工具，通过捕获上游 TiDB 的数据变更日志，可以将数据解析为有序的行级变更数据输出到下游。TiCDC 可以在多个 TiDB 集群中提供跨区域数据高可用和容灾方案，保证主备集群数据的最终一致性。

使用 TiCDC 实现同城两中心容灾，需要在主中心和同城中心分别部署一套集群，TiCDC 实时拉取主集群的数据变更，在内部进行排序合并处理之后，通过多个同步任务并发的向同城集群进行数据同步。相较于 DR Auto-Sync 的部署方案，TiCDC 方案对网络要求不高，可以灵活应对集群级的问题，但是 TiCDC 属于异步数据同步，无法保证 RPO=0 的要求，适用于非核心业务系统但有容灾要求的场景或直接应用于异地灾备场景。

二． OceanBase 同城两中心方案

根据官方文档介绍，对于同城两中心容灾场景，OceanBase 推荐采用“主 - 备”部署模式。也就是说，在两个中心分别部署一套 OceanBase 集群，集群间通过 RedoLog 做数据同步，形式上类似于传统数据库的“主从复制”模式，主库异步同步到备库，类似 Oracle Data Guard 中的“最大性能”模式。

从官网文档看，OceanBase 暂时没有提供可以实现 RPO=0 的同城两中心容灾方案。OceanBase 提出的“主 - 备”复制模式等同于 TiDB 提供的 TiCDC 方案，只适用于非核心业务系统但有容灾要求的场景或直接应用于异地灾备场景。

三． TDSQL 同城两中心方案

与 TiDB 和 OceanBase 的原生分布式架构不同，TDSQL 是典型的分库分表架构，底层数据存储在多个 MySQL 实例中。每个 MySQL 存储一个数据分片，为了保证单实例的高可用，一个 MySQL 分片实例通常还有多个 MySQL 从库保证高可用，这样的一组 MySQL 分片称为一个 SET。TDSQL 底层是由多个 SET 组成的存储引擎，计算节点无状态，元数据信息及路由信息保存在 Zookeeper。

在同城两中心架构中，TDSQL 建议每个数据库实例采用四节点模式分布在 2 个数据中心，数据库实例采用同 IDC 异步同步跨 IDC 强同步部署，Zookeeper 的多数派只能在两个机房中二选一。

因为 Zookeeper 也要满足多数派提交机制，假如是 3 个节点，那么针对 ZK 的分配有两种方式，即多数派在主机房还是多数派在备机房。无论是哪种方式，底层存储引擎的同步方式都是一样的，即前面所述的跨 IDC 强同步，同 IDC 异步同步。

ZK 多数派部署在备中心

首先此方案是跨中心强同步的，即满足 RPO=0。由于 ZK 多数派部署在备中心，当主中心故障后能自动切换到备中心，实现数据中心容灾切换下数据零丢失。但是如果备中心发生故障会导致主中心不可用，这类似于 Oracle 中的“最大保护”模式。

ZK 多数派部署在主中心

上个方案备中心故障会导致主中心不可用，带来较大的可用性问题。这个方案是将 ZK 多数派放到主中心，当备中心故障时系统退化成主机房强同步模式。对比前面的内容发现，这个模式相当于 Oracle 的“最大可用”模式。

细心的你可能会有一个疑问：TiDB 中的 PD 组件也是负责元数据管理和全局授时，它也是需要满足多数派的，为什么 TiDB 中的 PD 模块没有考虑 TDSQL 中的 Zookeeper 分布问题呢？我的理解是 TiDB 中 PD 的元数据主要是 Region 的位置数据，这些数据是每个 TiKV 节点和 Region 主动定时上报给 PD 的。即使多数派 PD 故障少数派 PD 数据有缺失，也不会影响集群，因为 TiDB 内部有自动重试的机制，当发现 PD 中的数据和 Region 实际位置不匹配会触发主动更新 PD 的过程。PD 的另外一个功能就是生成全局唯一 ID，这个也没有问题，如果少数派 PD 的全局唯一 ID 落后了，只要在切换后用 PD 自身的 recover 机制强制将 ID 修改为一个较大的值即可。

对比 TiDB 的同城两中心方案，TDSQL 中“ZK 多数派部署在主机房”和 DR Auto-Sync 有些类似，都比较接近于 Oracle 的“最大可用”模式。但相比于 DR Auto-Sync 而言，TDSQL 的这个方案在主中心故障后会由于 ZK 只有少数派而存在一致性风险。

四． GoldenDB 同城两中心方案

GoldenDB 是与 TDSQL 类似的分库分表架构，计算引擎、存储引擎模块几乎都差不多，两者主要的区别在于管理模块和事务处理模块。在管理模块上，GoldenDB 没有使用 Zookeeper 组件，而是自研了相关模块，如 MetadataServer、ProxyManager 及 ClusterManager。GoldenDB 具有全局事务节点 GTM，针对事务处理这部分，GoldenDB 使用的是比较独特的一阶段提交 + 自动补偿机制。GoldenDB 认为一般情况下需要回滚的事务比例占少数，而一阶段提交可以最大化提升事务处理的效率。

GoldenDB 底层存储也是使用多个 MySQL 分片，每个 MySQL 分片及从库称为一个 DBGroup，对应 TDSQL 的一个 SET。GoldenDB 在原生 MySQL 主从复制的基础上增加了诸多优化，比如保证数据不丢失、高并发下性能提升 50% 以及可控的同步策略，GoldenDB 将其命名为快同步复制 (gSync)。

基于 gSync 快同步复制能力，GoldenDB 增加了组响应策略，将不同数据中心的 DBGroup 划分为不同的组，如下图中的 team1/team2/team3。同时 GoldenDB 也实现了类 Oracle 的最大保护策略、最高性能策略和最高可用策略。

在同城两中心容灾方案里，对比上述其他产品，GoldenDB 的最高可用策略与 TiDB 的 DR Auto-Sync 类似，即正常情况下保证两个中心的 RPO=0，当发生故障时最大程度保证服务的可用性。GoldenDB 的最大保护策略与 TDSQL 中 ZK 多数派部署在备中心方案类似，当有一个中心故障时整体服务不可用。GoldenDB 的最高性能策略则相当于 TiDB 中的 TiCDC 方案以及 OceanBase 的异步复制方案。

五． GaussDB 同城两中心方案

首先声明一下，这里我们介绍的 GaussDB 是 GaussDB(for openGauss)。据相关资料说明，GuassDB 的同城两中心方案中需要部署主备两套集群，这与 TiDB 的 TiCDC 以及 OceanBase 的主备方案类似。然而，与 TiCDC 和 OB 主备方案不同的是，GaussDB 的主备集群是能够保证 RPO=0 的。那么 GaussDB 是怎么做的呢？

GaussDB 是把主集群的 Redo 日志通过存储层数据复制技术同步到备集群的存储设备中，备集群的备节点从所在分片的存储设备中读取 Redo 日志并进行回放。当主节点写入的日志同步到备集群的存储设备之后，主节点的事务才会提交，从而确保 RPO=0 的要求。存储设备采用的是华为自研的 OceanStor Dorado V6 全闪存存储系统，具有远程复制数据的功能。

这么看来，GaussDB 的同城两中心容灾方案与上述其它几个产品均有所不同，因为它使用的是存储层的复制技术，而上述几种产品的数据同步要么是基于 Raft 要么是基于 binlog 的日志复制技术。

六．总结

基于上述各种数据库提供的同城两中心容灾方案，笔者使用以下表格做一个总结对比，仅限个人观点，供大家参考。整体来说，如果是在核心业务系统中想做同城容灾并想保证 RPO=0 的要求，比较适合的有 TiDB 的 DR Auto-Sync、GoldenDB、GaussDB、TDSQL。如果不需要保证 RPO=0，应用于一些非核心类且有容灾要求的系统中，可以选择 TiDB 的 TiCDC 以及 OceanBase 的主备方案。