跳到主要内容

TiDB多活方案

作者:代晓磊_Mars 发表于 2022-05-30

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的,因为这个只是探测和切换的时间是由自动脚本或者监控来控制,所以可以实现主集群不可用时的及时切换。

ticdc.png

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

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

同城双中心

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

部署架构

two-dc-replication-1.png

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

(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复制协议完成。同城三数据中心可同时对外进行读写服务,实现了任意中心发生故障不影响可用性。

简易架构图

deploy-3dc.png

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

(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个读写数据中心、异地灾备中心的高可用容灾方案,相比同城多中心方案,两地三中心可以应对城市级自然灾害,具有跨城级高可用能力。

下图为集群部署架构图,具体如下:

three-data-centers-in-two-cities-deployment-02.png

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

(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官网