TiDB 4.0 基于 Binlog 的跨机房集群部署
原文来源:https://tidb.net/blog/1f9f96a4
作者:靳献旗,汽车之家 DBA
【是否原创】是
【首发渠道】TiDB 社区
【目录】
1. 背景介绍
2. 跨机房方案概述
3. 工作原理
4. 集群架构
5. 部署步骤
6. 线上使用情况
7. 展望
【正文】
1. 背景介绍
公司要求对 0 级应用做跨机房部署,当 A 机房整体故障时,业务可以快速切到 B 机房继续提供服务。恰好也涉及到了几套 TiDB 集群相关业务,这里做一下总结和回顾,希望能够帮助需要的用户。本文主要涉及下面几项内容:
● 几种基于 TiDB 的跨机房部署方案及优缺点
● 基于 Binlog 跨机房双向复制的详细部署步骤
● 线上 TiDB 跨机房使用情况及展望
2. 跨机房方案概述
下面介绍下 TiDB 几种跨机房集群部署方案的优缺点:
| 序号 | 方案 | 优点 | 缺点 || – | ——————————- | ————————————————————————————— | ——————————————————————————- || 1 | 同城三中心 | 是完美适配 TiDB 的部署方式 1. 提供单一中心故障的自动故障转移能力 2. 同城多活,资源最大化利用,所有副本都能参与计算 3. 较低的成本 (同城裸光纤) | 绝大多数用户不具备同城三中心条件 || 2 | 同城双中心可用区方案 (同中心的多个可用区在一定程度上物理隔离) | 1. 提供单一可用区故障的自动故障转移能力 2. 同城多活,资源最大化利用,所有副本都能参与计算 3. 较低的成本 (同城裸光纤) | 无法容忍包含多个可用区的机房整体故障 || 3 | 两地三中心 | 1. 提供单一可用区故障的自动故障转移能力 2. 同城双活 | 1. 成本过高 2. 收益低 (高网络延迟,异地中心的部分不参与计算) 3. 只依赖异地的副本无法恢复一致性 (RPO=0) 的数据,其异地容灾能力与主从集群方案差别不大 || 4 | 同城双中心 Raft 复制 | 1. 提供灾备中心故障的自动故障转移能力 2. 同城双活 3. 资源最大化利用,所有副本都能参与计算 4. 较低的成本 (同城裸光纤) | 只能容忍灾备机房故障,缺乏实际意义 || 5 | 同城双中心自适应同步复制 | 1. 提供灾备中心故障的自动故障转移能力 2. 提供主中心故障时的灾备机房数据手工恢复的能力 3. 同城双活 4. 资源最大化利用,所有副本都能参与计算 5. 较低的成本 (同城裸光纤) | 方案还外部试点测试中,预计 2021 年下半年达到生产级别可用 |
目前公司是同城双中心,因此上述方案排除掉 1、2、3 方案,4 方案缺乏实际意义,5 方案还不成熟,所以 4、5 也排除掉。难道没有方案可用?下面还有两种方案没提到,这里从技术层面分析下两种方案的优缺点。
| 序号 | 方案 | 优点 | 缺点 || – | ————– | ————— | ————————– || 6 | 基于 Binlog 双向复制 | 1. 成熟稳定 | 1.Drainer 不具备高可用 2. 并发处理不足 || 7 | 基于 TiCDC 双向复制 | 1. 具备高可用 2. 并发处理强 | 1. 官方未 GA 2. 内存使用较大 3. 复制中断问题 |
经过分析,我们最终选择了过度方案 6 :基于 Binlog 双向复制部署跨机房集群。后续时间成熟,我们会升级到方案 7 或者 5。
3. 工作原理
下面简单描述下基于 Binlog 双向同步的工作原理
在 A 和 B 两个集群间开启双向同步,则写入集群 A 的数据会同步到集群 B 中,然后这部分数据又会继续同步到集群 A,这样就会出现无限循环同步的情况。如上图所示,在同步数据的过程中 Drainer 对 Binlog 加上标记,通过过滤掉有标记的 Binlog 来避免循环同步。详细的实现流程如下:
(1) 为两个集群分别启动 TiDB Binlog 同步程序。
(2) 待同步的事务经过 A 的 Drainer 时,Drainer 为事务加入 _drainer_repl_mark 标识表,并在表中写入本次 DML event 更新,将事务同步至集群 B。
(3) 集群 B 向集群 A 返回带有 _drainer_repl_mark 标识表的 Binlog event。集群 B 的 Drainer 在解析该 Binlog event 时发现带有 DML event 的标识表,放弃同步该 Binlog event 到集群 A。
● 注意事项:
集群间双向同步的前提条件是,写入两个集群的数据必须保证无冲突,即在两个集群中,不会同时修改同一张表的同一主键和具有唯一索引的行。
更详细的内容请参考官方文档
4. 集群架构
集群信息如下:
集群 A (位于机房 A,ip 做了脱敏处理)
集群 B (位于机房 B,ip 做了脱敏处理)
集群架构如下
5. 部署步骤
本节详细介绍基于 Binlog 的跨机房部署步骤,这里以 TiDB 4.0.9 版本为例,对一个线上未开启 Binlog 的集群配置跨机房复制。主要分为两部分配置:A 集群配置,B 集群配置。
● A 集群配置步骤概要
(1)A 集群部署 Pump
(2)A 集群开启 Binlog
(3)A 集群导出全量数据,将全量数据导入 B 集群
(4)A 集群配置 drainer ,实现增量复制
● B 集群部署步骤概要
(1)B 集群部署 Pump
(2)B 集群开启 Binlog
(3)B 集群配置 drainer ,实现反向复制
5.1 A 集群部署步骤
【 A 集群部署 Pump 】
编写 Pump 扩容拓扑配置
执行下面命令扩容 Pump
查看 Pump 状态
登录 TiDB 查看 Pump 状态
【 A 集群开启 Binlog 】
编辑 A 集群配置文件开启 Binlog
滚动重启 TiDB-server
登录 TiDB 确认当前集群是否开启 Binlog
【 A 集群导出全量数据,将全量数据导入 B 集群 】
1.A 集群导出全量数据
2. 将全量数据导入 B 集群
【 A 配置 Drainer 实现增量复制 】
编写 Drainer 扩容拓扑配置
执行下面命令扩容 Drainer
查看 Drainer 状态
4. 登录 TiDB 查看 Drainer 状态
5.2 B 集群部署步骤
【 B 集群部署 Pump 】
编写 Pump 扩容拓扑配置
执行下面命令扩容 Pump
查看 Pump 状态
登录 TiDB 查看 Pump 状态
【 B 集群开启 Binlog 】
编辑 B 集群配置文件开启 Binlog
滚动重启 TiDB-server
确认当前集群是否开启 Binlog
【 B 配置 Drainer 实现反向复制 】
编写 Drainer 扩容拓扑配置
执行下面命令扩容 Drainer
查看 Drainer 状态
4. 登录 TiDB 查看 Drainer 状态
5.3 测试双向复制
我们重点对下面几种场景做了测试:
| 序号 | 测试内容 | 测试结果 || – | ——————— | —- || 1 | A 集群数据同步到 B 集群是否正常 | 正常 || 2 | B 集群数据同步到 A 集群是否正常 | 正常 || 3 | A 集群 DDL 同步到 B 集群是否正常 | 正常 || 4 | B 集群 DDL 不能同步到 A 集群 | 无法同步 |
6. 线上使用情况
目前线上有 3 套 TiDB 集群做了跨机房部署,如下表所示:
7. 展望
基于 Binlog 的跨机房部署方案运行比较稳定,但是存在一些缺点:并发处理能力不足,无法做到高可用。因此基于 Binlog 的方案目前属于过度方案,我们还是希望不久的将来能够使用基于 TiCDC 的方案替代 Binlog 方案,TiCDC 弥补了上述 Binlog 的不足,也是官方大力开发并支持的方案。
介于目前 TiCDC 的双向同步方案还没正式 GA,而且存在一些问题,例如使用内存较多,同步中断等。值得期待的是,官方正在大力推进测试,应该会在 2021 年第三季度可以 GA。届时,我们将重点进行测试,让我们拭目以待。
版权声明: 本文为 InfoQ 作者【TiDB 社区干货传送门】的原创文章。
原文链接:【http://xie.infoq.cn/article/e59893247d727c9f061d4e494】。文章转载请联系作者。
评论