TiDB 多活方案

作者： 代晓磊 _Mars 原文来源：https://tidb.net/blog/4136de6f

TiDB 的多活一直是各个将 TiDB 用到核心场景的互联网公司都在努力实现的高可用方案。为了实现分布式数据库的可用性要求，通常采用多中心部署方案，以保证高可用和容灾能力。多中心部署方案包括同城主备集群，同城双中心，同城三中心、两地三中心等多种部署模式。

同城多中心方案一般硬性要求：

（1）数据中心距离在 50 km 以内，通常位于同一个城市或两个相邻城市

（2）数据中心间的网络采用 2 条光纤专线连接，并且要求延迟小于 1.5 ms，并且长期稳定运行

（3）双专线且带宽大于 10 Gbps。

在讲多活之前先给大家普及几个概念：

• RPO：Recovery Point Objective，数据恢复点目标，也就是说业务能容忍数据丢失量，核心业务一般要求 RPO=0。

• RTO：Recovery Time Objective，恢复时间目标，也就是说业务能接受的最大不可用时间，一般都要求 RTO<30s。

• Muti-raft：raft 是分布式一致性算法，tikv 的底层多个 region 副本 (默认 3 副本) 是通过日志复制来实现数据同步，并且靠多个 raft group(成员有“身份”) 来投票来获得 leader/follwer 身份，tikv 的数据写入是靠 raft group 中的多数节点写入成功才算成功。

所以在多活的场景中的建议：

• 服务器容灾：至少提供 3 台服务器来避免单 host 宕机导致的集群不可用。

• 机架容灾：至少提供 3 个机柜来避免单机柜 (rack) 故障导致的集群不可用。

• 机房容灾：至少提供 3 个数据中心来避免单数据中心 (DataCenter) 故障导致的集群不可用。

• 城市容灾：至少规划 3 个城市来避免单城市灾难引发的集群不可用。

注：这也是俗话说的鸡蛋不要放在一个篮子里的原因。

主备集群

这里主要提到的是基于 TiCDC 的同城、跨城的数据同步。

这些对于所有核心 tidb 都放在同一个机房的公司，如果机房孤岛或者其他灾害问题，业务无法及时恢复。所以说 TiDB 集群的主备集群需求是重要的需求。TiCDC 作为 TiDB 生态中重要的一环，通过 ticdc cluster 实时拉取 tikv 的 changelog 并且应用到下游集群，从而实现了同城 / 跨城的主备集群数据同步，有了主备集群，一是可以将部分不需要太实时的读取流量切到备用集群，来缓解主 TIDB 集群的读取压力。二是一旦核心机房有问题，备用集群就可以立即接管服务，因为经过了 ticdc 这层同步中间件，所以 RPO 受主库写入情况，以及 ticdc sink 速度的限制，存在 RPO！=0 的情况，RTO 肯定是能做到小于 30s 的，因为这个只是探测和切换的时间是由自动脚本或者监控来控制，所以可以实现主集群不可用时的及时切换。

PS：本文主要讲基于 Placement-rule 的多中心方案，所以这种“异步复制”的 ticdc 工具就不展开讲了，如果大家有想对 TiCDC 更加深入的了解，去年我写过一篇：TiCDC 应用场景解析 的文章，大家可以跳转详细看看。

下面要讲的几套多城多活方案，都是基于 Placement-Rule 配置实现的同一套 TiDB 跨多城 / 多数据中心的部署架构。

同城双中心

其实在 TiDB 4.0 版本就出现了使用 Placement rule 来配置的集群 (这套同城双中心的方案官方没有放出来)，不过在 TiDB 的 5.4 版本出现了一种基于自适应同步（即 Data Replication Auto Synchronous，简称 DR Auto-Sync）同城两中心部署方案，下面主要介绍下这个自适应同步方案架构。

部署架构

通过查看上面的集群部署架构图：

（1）这套架构将一套 TiDB 集群部署在同一个城市的 2 个 IDC 机房 (注意要满足硬性要求)，一个是主数据中心 (PRIMAY IDC)，一个是从数据中心 (DR DC)

（2）集群采用 4 副本模式，其中主数据中心放 2 个 Voter 副本，从数据中心中放 1 个 Voter 副本 + 1 个 Learner 副本，也就是 3 个 voter 和 1 个没有投票资格的 Learner，并且 Leader 在主数据中心

（3）自适应同步，TIDB 集群的复制模式可以自动在 sync/async/sync-recover 三种状态之间自适应切换。

• 在默认的同步模式 (sync) 下，Raft 来保证从数据中心中至少有一个副本保持跟主数据中心同步，这样的情况下，如果主数据中心不可用（2 个 Voter 都不可用），这时 raft 是没法选出 Leader 的，这至少数据不丢（RPO=0），因为从数据中心有最新的数据，只是如果要把从数据中心当作新主来使用时需要 tikv-ctl 来恢复，这个时候恢复时间就不好评估了 (RTO>N)，关于如何恢复？参考我之前的写过的：TiDB 集群恢复之 TiKV 集群不可用。

• 如果从机房网络故障时，超过 PD 参数 wait-store-timeout(默认 60s)，主从中心间的数据同步就会切换到 async(异步复制模式)，在这种情况下，raft 算法优先保证主数据中心的 2 个副本写入 (Voter 的多数派写入成功，事务可以提交)，从数据中心靠异步复制获取的不是最新的数据。这是主机房读写都正常 (RPO=0 & RTO=0)

• 当从机房网络故障恢复时，主从数据中心的同步由异步切换到 sync-recover(恢复同步)，此时不保证 DR 与 PRIMARY 完全同步，随着恢复的进行，从 region 会不断的将状态汇报给 PD，当 TiKV 的所有 Region 都完成了同步复制模式的切换，PD 将集群复制状态切换为 sync。

特点：

（1）同城双中心，在同步模式下能实现 RPO=0，如果从数据中心不可用，不影响（RTO=0）

（2）在非同步模式下，如果主数据中心不可用，不能实现 RPO=0，RTO 也不可控可能分钟或者小时，需要 tikv-ctl 工具来操作将从数据中心多久提升为主数据中心。

同城三中心

同城三中心方案应该是当前最常规的高可用方案，需要同城有三个机房或者云厂商的三个可用区，数据中心间的数据同步通过内部的 raft 复制协议完成。同城三数据中心可同时对外进行读写服务，实现了任意中心发生故障不影响可用性。

简易架构图 

通过查看上面的集群部署架构图：

（1）这套架构将一套 TiDB 集群部署在同一个城市的 3 个 IDC 机房，所有数据中心都有 tidb/pd/tikv，所有的数据中心都可以接受读写服务。

（2）集群采用默认 3 副本即可，并且 3 个数据中心都有 region 的 Leader/Follower 副本。基于 raft 的多数派写入逻辑，至少有 2 个数据中心有最新的数据，所以任何一个数据中心不可用，不会产生任何数据丢失 (RPO = 0)，但是在不可用数据中心的 Leader 副本会触发 raft 的 leader 选举，该选举新 Leader 有一定的时间，差不多在在 30s 内，所以 RTO<30s。

（3）该架构受机房间网络的速率、稳定性等硬性条件关联紧密，比较适合读多写少，或者对写入不“敏感”的业务。就算数据中心延迟稳定在 1.5ms 内，数据写入需要保证多数派写入的情况下，肯定会发生跨数据中心的写入，这时写入延迟肯定大于基本的网络延迟：1.5*2=3ms，所以写入敏感的业务慎用；对于读取场景，如果请求的 region leader 在另外的数据中心，也会受网络延迟影响，读取按照具体的业务场景也可以选择 follower/steal read。

集群架构特点：

所有数据的副本分布在三个数据中心，具备高可用和容灾能力，读写性能受数据中心之间网络延迟的影响较大，所以同城三中心的架构需要适配具体的业务场景来应用。

两地三中心

两地三中心是以本地的 2 个读写数据中心、异地灾备中心的高可用容灾方案，相比同城多中心方案，两地三中心可以应对城市级自然灾害，具有跨城级高可用能力。

下图为集群部署架构图，具体如下：

通过查看上面的集群部署架构图：

（1）集群采用两地三中心部署方式，分别为北京 IDC1 机房 (本地读写机房)，北京 IDC2 机房 (本地读写机房)，西安 IDC3 机房 (异地灾备机房)；所有数据中心都部署 tidb/pd/tikv。

（2）集群采用 5 副本模式，其中 IDC1 和 IDC2 分别放 2 个副本，IDC3 放 1 个副本，可以通过 PD 调度实现所有的 Leader region 都在北京的 2 个读写数据中心，所以读写都在北京本地，读写性能跟同城三中心类似，取决于数据中心间的网络情况，西安的数据中心只有 follower 节点，还保留了一份异步的数据。

（3）副本间通过 Raft 协议保证数据的一致性和高可用，对用户完全透明。

集群架构特点：

（1）本地两中心可同时对外提供服务，资源利用率更高。

（2）可保证任一数据中心失效后，不发生数据丢失（RPO=0），可用性也可以在分钟级别恢复（RTO 分钟级）。

（3）如果本地两中心不可用，那就剩下西安的数据中心，由于 raft 的配置，西安的数据中心可能没有获取到最新的数据，也就是说不能保证 RPO=0，因为多数的副本不可用，集群不可用，所以 RTO 的时间也是借助 tikv-ctl 实现数据恢复后的总时长。

（4）两地三中心需设置 5 副本，数据冗余度增加，增加硬盘空间成本。

总结

如果只有同城双机房，本人使用过基于 ticdc 的主备方案，真正意义上的多活，还是同城三中心。

注：本文主要参考 TiDB 集群已有方案，文中多图都来自于 tidb 官网