HULK云数据库：TiDB集群多机房高可用

TiDB作为一款分布式、金融级高可用数据库，数据采用多副本存储，数据副本通过 Multi-Raft 协议同步事务日志，多数派写入成功事务才能提交，确保数据强一致性且少数副本发生故障时不影响数据的可用性。还可以按需配置副本地理位置、副本数量等策略，满足不同容灾级别的要求。目前HULK TiDB存在两种型态的集群高可用，一种是基于上述理论的单集群同域多机房高可用，一种是基于DTS同步工具的跨集群机房高可用。

二、TiDB多机房高可用介绍

2.1 单集群同域多机房

同区域三机房方案，即同区域有三个机房部署 TiDB 集群，机房间的数据在集群内部（通过 Raft 协议）进行同步。同区域三机房可同时对外进行读写服务，任意机房中心发生故障不影响数据一致性感知。

图2.1.1 集群机房分布图

优点：

• 所有数据的副本分布在三个机房，具备高可用和容灾能力

• 任何一个AZ 失效后，不会产生任何数据丢失 (RPO = 0)

• 任何一个AZ 失效后，其他两个AZ 会自动发起 leader election，并在一定时间内（通常 20s 以内）自动恢复服务

• 采用区域多机房方案，当任意一个机房故障时，集群能自动恢复服务，不需要人工介入，并能保证数据一致性

图2.1.2 机房一节点失活

缺点：

性能受网络延迟影响。具体影响如下：

• 对于写入的场景，所有写入的数据需要同步复制到至少两个 机房，由于 TiDB 写入过程使用两阶段提交，故写入延迟至少需要两倍机房间的延迟。

• 对于读请求来说，如果数据 leader 与发起读取的 TiDB 节点不在同一个 AZ，也会受网络延迟影响。

• TiDB 中的每个事务都需要向 PD leader 获取 TSO，当 TiDB 与 PD leader 不在同一个 AZ 时，TiDB 上运行的事务也会因此受网络延迟影响，每个有写入的事务会获取两次 TSO。

2.2 DTS多集群数据同步

搭建一主一备两个TiDB集群，通过DTS数据同步工具将主TiDB集群的数据同步到备TiDB集群，目前HULK底层使用的TiCDC工具进行数据同步。

图2.2.1 线上ticdc高可用架构图

优点：

• 同一个集群所有数据副本分布在同一个机房，不受网络影响。

• 副集群可以用来提供数据分析任务，降低对在线业务的影响。

缺点：

数据同步具有局限性：

• 不支持：

• 系统表（如mysql.*和information_schema.*）的 DDL 和 DML 语句。

• 临时表的 DDL 和 DML 语句。

• DQL (Data Query Language) 语句 和 DCL (Data Control Language)语句。

所以需要手动处理主集群的用户权限表同步到备集群。

速度同步具有局限性：

• 大表同步：

• 从 v7.1.0 起，TiCDC 支持 MQ sink 按照 TiKV Region 粒度来同步数据变更日志，实现处理能力上的可扩展性，使得 TiCDC 能够同步 Region 数量庞大的单表，开关受enable-table-across-nodes = true 参数控制

• 索引操作 (ADD INDEX, CREATE INDEX)：为了减少对 Changefeed 同步延迟的影响，当下游为 TiDB 时，TiCDC 会异步执行创建和添加索引的 DDL 操作。

事务同步具有局限性：

• TiCDC 对大事务（大小超过 5 GB）提供部分支持，根据场景不同可能存在以下风险：

• 可能导致主从同步延迟大幅增高。

• 当 TiCDC 内部处理能力不足时，可能出现同步任务报错 ErrBufferReachLimit。

• 当 TiCDC 内部处理能力不足或 TiCDC 下游吞吐能力不足时，可能出现内存溢出 (OOM)。

    虽然从V6.2TiCDC 支持拆分单表事务功能，可大幅降低同步大事务的延时和内存消耗。但是这是在牺牲业务对事务原子性要求不高的情况下才能实现，可以通过设置 sink uri 参数 transaction-atomicity 打开拆分事务功能以解决可能出现的同步延迟和 OOM 问题。

业务访问具有局限性：

• 当主集群异常，提升备集群提供服务时，业务需要变更VIP地址，即使使用域名也会有域名生效时间。

三、多机房高可用原理简述

下面主要根据以上两种高可用方案，进行相关高可用原理简介。

3.1 单集群同域多机房原理

单集群同域多机房主要是使用了TiDB的Labels标签功能。

TiKV 是一个 Multi-Raft 系统，其数据按 Region（默认 96M）切分，每个 Region 的 3 个副本构成了一个 Raft Group。假设一个 3 副本 TiDB 集群，由于 Region 的副本数与 TiKV 实例数量无关，则一个 Region 的 3 个副本只会被调度到其中 3 个 TiKV 实例上，也就是说即使集群扩容 N 个 TiKV 实例，其本质仍是一个 3 副本集群。

由于 3 副本的 Raft Group 只能容忍 1 副本故障，当集群被扩容到 N 个 TiKV 实例时，这个集群依然只能容忍一个 TiKV 实例的故障。2 个 TiKV 实例的故障可能会导致某些 Region 丢失多个副本，整个集群的数据也不再完整，访问到这些 Region 上的数据的 SQL 请求将会失败。而 N 个 TiKV 实例中同时有两个发生故障的概率是远远高于 3 个 TiKV 中同时有两个发生故障的概率的，也就是说 Multi-Raft 系统集群扩容 TiKV 实例越多，其可用性是逐渐降低的。

正因为 Multi-Raft TiKV 系统局限性，Labels 标签应运而出，其主要用于描述 TiKV 的位置信息。Label 信息随着部署或滚动更新操作刷新到 TiKV 的启动配置文件中，启动后的 TiKV 会将自己最新的 Label 信息上报给 PD，PD 根据用户登记的 Label 名称（也就是 Label 元信息），结合 TiKV 的拓扑进行 Region 副本的最优调度，从而提高系统可用性。

TiDB的标签使用主要受以下参数控制：

replication.location-labels: ["zone", "host"]，该参数控制隔离级别从左往右依此减弱，首先按照zone进行region分布，zone都一样再按照host进行数据分布。

isolation-level ： "zone"，控制在物理层面上的最低隔离要求

假如 isolation-level 设置值为 zone，这样就规定了 Region 副本在物理层面上的最低隔离要求，也就是说 PD 一定会保证同一 Region 的副本分散于不同的 zone 之上。即便遵循此隔离限制会无法满足 max-replicas 的多副本要求，PD 也不会进行相应的调度。例如，当前存在 TiKV 集群的三个可用区 z1/z2/z3，在三副本的设置下，PD 会将同一 Region 的三个副本分别分散调度至这三个可用区。若此时 z1 整个可用区发生了停电事故并在一段时间后（由 max-store-down-time 控制，默认为 30 分钟）仍然不能恢复，PD 会认为 z1 上的 Region 副本不再可用。但由于 isolation-level 设置为了 zone，PD 需要严格保证不同的 Region 副本不会落到同一 zone 上。此时的 z2 和 z3 均已存在副本，则 PD 在 isolation-level 的最小强制隔离级别限制下便不会进行任何调度，即使此时仅存在两个副本。

以下是一个TiDB的高可用集群拓扑YMAL文件，文件中给TiKV节点设置了lable标签，部署之后就会完成数据在三个机房均匀分布。

global:  user: "root"  ssh_port: 22  deploy_dir: "/data/tidb_cluster/tidb-deploy"  data_dir: "/data/tidb_cluster/tidb-data"server_configs:  tikv:    server.grpc-compression-type: gzip  pd:    replication.location-labels:  ["zone","host"] # PD 会根据 TiKV 节点的zone 和 host配置来进行副本的调度。pd_servers:  - host: 10.xx.xx.01    name: "pd-1"  - host: 10.xx.xx.02    name: "pd-2"  - host: 10.xx.xx.03    name: "pd-3"tidb_servers:  - host: 10.xx.xx.01  - host: 10.xx.xx.01  - host: 10.xx.xx.01tikv_servers:  # 在 TiKV 节点中通过 labels 选项来对每个 TiKV 节点所在的 zone 和 host 进行标记  - host: tidb-dr-test1    config:      server.labels: { zone: "beijing01", host: "10.xx.xx.04" }  - host: tidb-dr-test2    config:      server.labels: { zone: "beijing02", host: "10.xx.xx.05" }  - host: tidb-dr-test3    config:      server.labels: { zone: "beijing03", host: "10.xx.xx.06" }

3.2 DTS多集群数据同步原理

TiCDC 集群由多个 TiCDC 对等节点组成，是一种分布式无状态的架构设计。TiCDC 集群及节点内部组件的设计如下图所示：

图3.2.1  ticdc集群高可用原理图

上图中，TiCDC 集群由多个运行了 TiCDC 实例的节点组成，每个 TiCDC 实例都运行一个 Capture 进程。多个 Capture 进程中会有一个被选举成为 Owner Capture，负责完成 TiCDC 集群的负载调度、DDL 语句同步和其它管理任务。

每个 Capture 进程包含一个或多个 Processor 线程，用于同步上游 TiDB 集群中的表数据。由于 TiCDC 同步数据的最小单位是表，所以 Processor 是由多条 table pipeline 构成的。

图3.2.2 单表处理数据流转图

各个模块之间是串行的关系，组合在一起完成从上游拉取、排序、加载和同步数据到下游的过程，其中：

• puller：从 TiKV 节点获取 DDL 和行变更信息。

• Sorter：将接收到的变更在 TiCDC 内按照时间戳进行升序排序。

• Mounter：将变更按照对应的 Schema 信息转换成 TiCDC 可以处理的格式。

• Sink：将对应的变更应用到下游系统。

为了实现高可用，每个 TiCDC 集群都包含多个 TiCDC 节点，这些节点定期向 PD 集群中的 etcd 集群汇报自己的状态，并选举出其中一个节点作为 TiCDC 集群的 Owner。Owner 采用 etcd 统一存储状态来进行调度，并将调度结果直接写入 etcd。Processor 按照状态完成对应的任务，如果 Processor 所在节点出现异常，集群会将表调度到其他节点。如果 Owner 节点出现异常，其他节点的 Capture 进程会选举出新的 Owner，如下图所示：

图3.2.3 ticdc高可用原理图

四、HULK云平台TiDB多机房高可用使用

目前HULK云平台已经对部分集群实现了以上两种型态的集群高可用。

4.1 单集群同域多机房使用

目前线上对Serverless等公共集群进行了同域多机房高可用改造。从容量监控图可以看出，shrxx、shcxx、shyxx三个机房都是163G（因为是基于存量三节点集群进行的改造，所以有的机房三个节点，有的机房一个节点）

图4.1.1 节点容量监控图

各个机房region数量分布，其中shr、shc两个机房每个服务器上9.64K个region，shy机房所有服务器region 数量加和也是9.64K，数据均匀分布。

图4.1.2 节点region分布图

从监控图可以看出，三个机房的数据分布是符合预期的，每个机房9.6K个region。保证其中一个机房挂掉之后另外两个机房仍然能提供服务，相当于region副本3份只缺失一份。

而且从SQL耗时来开，同区域多机房耗时相对于单机房并没有明显增加，95%分布在6.29ms以下

图4.1.3 查询耗时图

4.2 DTS多集群使用

4.2.1主备集群同步监控图

目前为保证部分业务线集群高可用以及充分利用备集群进行一些数据分析，基于TiDB周边工具TiCDC进行数据同步实现集群高可用。

图4-2-1-1 Hulk TiCDC复制节点图

图4-2-1-1 Hulk 主备集群复制状态监控图

我们可以通过以上监控图确认当前主备集群同步是不是存在延迟，延迟较大要及时介入处理，防止备集群落后太多增加数据丢失的风险。

4.2.2主备集群同步告警图

为监测数据同步的有效性和实时性，添加了集群可用性和任务延迟告警，保证集群高可用有效性。

图4-2-2-1延迟性告警

图4-2-2-2服务存活告警

DBA会实时关注以上告警，保证集群高可用正常运行。

五、结语

目前HULK TiDB数据库服务，已实现了以上两种形态的集群高可用：

DTS这种架构看起来非常简洁，写入性能不受影响，可用性比较高，最大的错误容忍目标可以做到跨区域级别高可用，RPO 在秒级别，RTO 在分钟级别，甚至更低。备集群还可以进行一些复杂的分析查询而不影响主集群。但是进行高可用切换时需要业务变更访问地址，即使是域名模式也需要等待域名解析生效，如果 RPO 为 0 并不是必须满足的要求，推荐在重要生产系统使用该容灾方案。

单集群同域多机房方案最大的错误容忍目标可以达到同区域多机房级别，同等资源配置下，写能力也能够得到扩展（当然前提条件是多机房之间的网络延迟较低，否则写能力反而下降），并且 RPO 为 0，RTO 也可以达到分钟级别，甚至更低。如果 RPO 为 0 是必须满足的要求，推荐在重要生产系统使用该容灾方案。

业务可以根据自己的场景选择不同的高可用方案，高可用具体构建暂时可以咨询DBA进行人工操作，自动化产品型态正在开发中。

HULK云数据库产品，提供一站式全生命周期数据库服务自助管理能力，使用HULK云数据库产品，请至智汇云官网https://zyun.360.cn,联系客服为您添加账号权限。

更多技术干货，

请关注“360智汇云开发者”👇

360智汇云是以"汇聚数据价值，助力智能未来"为目标的企业应用开放服务平台，融合360丰富的产品、技术力量，为客户提供平台服务。

目前，智汇云提供数据库、中间件、存储、大数据、人工智能、计算、网络、视联物联与通信等多种产品服务以及一站式解决方案。

官网：https://zyun.360.cn（复制在浏览器中打开）

更多好用又便宜的云产品，欢迎试用体验~