国产数据库同城双中心容灾方案对比：TiDB展现卓越性能

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

一． 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状态。

对比***的三种容灾模式——最大保护模式、最大可用模式以及最大性能模式，可以看出，TiDB的DR Auto-Sync接近于***的最大可用模式，它是一种在正常情况下保证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的要求，适用于非核心业务系统但有容灾要求的场景或直接应用于异地灾备场景。

二． ***同城两中心方案

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

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

三． ***同城两中心方案

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

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

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

• ZK多数派部署在备中心

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

• ZK多数派部署在主中心

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

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

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

四． ***同城两中心方案

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

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

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

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

五． ***同城两中心方案

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

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

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

六． 总结

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

七． 参考链接

TiDB: 单区域双 AZ 部署 TiDB | PingCAP 文档中心

***: *** 集群高可用部署方案简介-*** 数据库-***文档中心-分布式数据库使用文档

***: ***多地多中心高可用方案设计 - 百度文库 (baidu.com)

***: ***分布式数据库容灾方案及实践 (qq.com)

***: 让数据库无惧灾难，****** 同城双集群高可用方案正式发布 (baidu.com)

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。