TiDB集群基于Binlog的跨机房高可用实践

总篇120篇 2021年第11篇1.?背景介绍之家要求对核心业务做跨机房部署，当 A 机房整体故障时，业务可以快速切换到 B 机房继续提供服务，提升业务容灾能力。涉及到了多套 TiDB 集群跨机房高可用布署,在此我对 TiDB 集群基于 Binlog 的跨机房高可用实践做下总结和回顾。本文主要涉及以下几项内容：● 几种基于 TiDB 的跨机房高可用方案及优缺点● 基于 Binlog 双向复制的高可用方案工作原理● 当前线上集群高可用架构及对未来的展望2.?跨机房高可用概述下面介绍下 TiDB 几种跨机房集群高可用方案的优缺点：通过以上分析，1、2 方案成本太高，3方案缺乏实际意义，4方案还在外部试点测试中，暂时未达到生产级别可用。难道没有方案可用？下面还有两种方案没提到，这里从技术层面分析下两种方案的优缺点。经过分析，我们最终选择了过度方案 5：基于 Binlog 双向复制部署跨机房集群。后续时间成熟，我们会升级到方案 4或者 6。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。● 注意事项：集群间双向同步的前提条件是，写入两个集群的数据必须保证无冲突，即在两个集群中，不会同时修改同一张表的同一主键和具有唯一索引的行。更详细的内容请参考官方文档https://docs.pingcap.com/zh/tidb/dev/bidirectional-replication-between-tidb-clusters#%E9%9B%86%E7%BE%A4%E9%97%B4%E5%8F%8C%E5%90%91%E5%90%8C%E6%AD%A54.?集群架构集群信息如下：集群架构如下5.?部署步骤本节简要介绍一下基于 Binlog 的跨机房部署步骤，如何对一个线上未开启 Binlog 的集群配置跨机房双向复制，主要分为两部分配置：A 集群配置，B 集群配置。5.1部署双向复制● A 集群配置步骤概要（1）A 集群部署 Pump（2）A 集群开启 Binlog（3）A 集群导出全量数据，将全量数据导入B 集群（4）A 集群配置 Drainer ，实现增量复制● B 集群部署步骤概要（1）B 集群部署 Pump（2）B 集群开启 Binlog（3）B 集群配置 Drainer ，实现反向复制5.2 测试双向复制我们重点对下面几种场景做了测试：测试结果满足业务需求。6.?展望基于 Binlog 的跨机房部署方案运行比较稳定，但是存在一些缺点：并发处理能力不足，无法做到高可用。因此基于 Binlog 的方案目前属于过度方案，我们还是希望不久的将来能够使用基于 TiCDC 的方案替代 Binlog 方案，TiCDC 弥补了上述 Binlog 的不足，也是官方大力开发并支持的方案。介于目前 TiCDC 的双向同步方案还没正式 GA，而且存在一些问题，例如使用内存较多，同步中断等。值得期待的是，官方正在大力推进测试，应该会在2022年 GA。届时，我们将重点进行测试，让我们拭目以待。作者简介