作者：自扬
列夫·托尔斯泰曾说“艺术源于生活，并高于生活”，他认为艺术不仅仅是生活的简单复制，而应该能够表达更深层次的意义和价值，从而达到“高于生活”的境界。PolarDB-X作为一款兼容MySQL的云原生分布式数据库，我们的目标也不仅仅是简单的兼容MySQL，而应该借助云原生的优势、分布式的扩展性优势做更深层次的能力演进，从而达到“超越MySQL”的境界，称之为“兼容MySQL，高于MySQL”。本文主要介绍一下PolarDB-X在CDC能力上那些高阶能力。
CDC Review
对PolarDB-X CDC不熟悉的同学，可以参考我们的知乎历史文章，奉上链接
- PolarDB-X 全局 Binlog 解读 https://zhuanlan.zhihu.com/p/369115822
- PolarDB-X 全局 Binlog 解读之 DDL https://zhuanlan.zhihu.com/p/377854011
- PolarDB-X 全局 Binlog 解读之理论篇 https://zhuanlan.zhihu.com/p/462995079
- PolarDB-X 全局Binlog 解读之高可用篇 https://zhuanlan.zhihu.com/p/614839581
- PolarDB-X 全局Binlog 解读之性能篇(上) https://zhuanlan.zhihu.com/p/580061494
- PolarDB-X 全局Binlog 解读之性能篇(下) https://zhuanlan.zhihu.com/p/603840937
- 如何兼容 MySQL Binlog 协议和参数 https://zhuanlan.zhihu.com/p/512114589
- 实践教程之PolarDB-X replica原理和使用 https://zhuanlan.zhihu.com/p/613010882
- PolarDB-X 源码解读（三）：CDC 代码结构 https://zhuanlan.zhihu.com/p/452174464
- 源码解读（八）：Global Binlog 的一生 https://zhuanlan.zhihu.com/p/501159425
透明消费
冷热数据的无感消费
PolarDB-X的CDC集群会优先把构建好的binlog文件保存在本地磁盘，并支持实时上传到远端存储（例如OSS）。本地磁盘上的文件(可以称之为热文件)一般存活周期较短，远端存储上的文件(可以称之为冷文件)存活周期较长（例如15天）。针对远端存储上的文件，CDC提供了透明消费能力，即屏蔽了本地和远端的存储差异，下游系统无需为访问远端存储上的binlog数据做任何额外适配。 直观的举例： 登录PolarDB-X的CDC节点，进入/home/admin/binlog目录，可以看到编号小于65的binlog文件，已经归档到OSS
本地binlog文件
归档到OSS的binlog文件
在Polardb-X 命令行执行show binary logs，小于65的文件仍然可见；执行show full binary logs，还可以显示每个binlog文件的详细信息：binlog event的开始时间和结束时间、binlog文件的上传状态、存储状态等
通过mysqlbinlog工具，可透明消费已经归档到OSS的文件，通过show binlog events，亦可
并且透明消费，还可以有不错的消费速度，超过200MB/s的吞吐
除此之外，我们还提供了内置的「SQL闪回」能力，选定需要闪回的时间段，不管binlog文件是在本地，还是已经归档到OSS，抑或是同时跨越了本地和归档，只要文件还存在，可以进行快速闪回，满足「数据修复」和「数据审计」等需求。打个广告：免费使用哦 ^_^
始终如一的连续消费
MySQL的主从复制存在一个令人“恼火”的设计：支持基于binlog_file_name + binlog_file_position 开始进行消费，但不能保证Master和Slave节点上binlog文件的连续性（即相同名字的binlog文件，在Master和Slave上对应的内容很可能是不一样的)，那么，当发生主从切换时，下游消费程序便无法基于之前的位点继续消费，需要引入各种“额外”的协调机制，如：
- 基于全局管理者的协调机制
主要用在MySQL的HA方案中，典型产品如MHA，其能够监测整个MySQL集群中不同节点的binlog复制状态，当需要进行HA切换时，通过一系列的日志补偿机制和切换算法，基于新的binlog_file_name和binlog_file_position对节点之间的复制关系进行重建。此处不详述，贴图贴链接，感兴趣的读者可以进行深入研究。
- 基于时间戳的自动协调机制。
主要用在数据同步链路Auto Recovery的场景下，典型产品如Alibaba Canal，其同步任务中，可以配置MySQL集群的多个节点，当一个节点不可用时，可以自动切换到另一个节点，此时会面临binlog位点不一致的问题，canal提供了基于时间戳的回溯机制，通过遍历binlog文件，找到这样一个binlog文件位点，该位点对应的binlog event的时间戳比HA切换前的已消费event的时间戳要小，即通过重复消费一个时间范围内的binlog event来实现HA切换，以保证不丢数据，当然这种模式下因涉及重复消费，需要消费程序具备“幂等”机制。此处不详述，贴图贴链接，感兴趣的读者可以进行深入研究。
针对这个让人“恼火”的问题，MySQL在5.7版本，正式引入了基于Gtid的复制方案，来弥补基于binlog_file_name + binlog_file_position的缺点，靠全局不重复的Gtid来屏蔽不同节点上的binlog文件差异，在很大程度上缓解了复杂性。但这里面有个前提，必须通过直接连接MySQL服务进程进行binlog消费，才能享受到这个便利性，如果binlog已经被归档，则还是需要通过binlog文件名字来进行管理和操作。 而现实情况是，归档后的binlog文件很可能是不连续的(如：发生过HA切换、节点重搭、跨机变配等操作)，比如下图所示，一个RDS MySQL的两个节点发生了跨机迁移，迁移之后两个新节点的binlog文件的编号重新从000001开始，并且新的000001文件和老节点最后一个binlog文件，还有一定时间范围的日志数据重合。
在上面这个场景中，如果有下游消费程序想从某个历史时间点开始消费binlog，则仍然要面对这种可能的“不连续”问题，属实很麻烦。而使用PolarDB-X的binlog，则完全不用担心此类问题，不论发生何种运维动作(升级、变配、重搭等等)，PolarDB-X能始终如一的保持binlog文件的连续性，为下游消费程序带来“透明无感”的使用体验。
再也没有“里程”焦虑
在进行数据同步时，常见的操作流程为，从某个时间点开始进行全量数据迁移，当全量数据迁移完成后，基于全量迁移开始的时间点通过回溯binlog追增量数据。在某些基于“事件溯源”思想构建软件架构的场景下，往往希望从很早的一个时间点（甚至是起始时间）开始消费binlog，来构造出新的应用数据。如上两个场景，都有将binlog保留足够长时间的需求，比如在使用DTS迁移数据时，在产品文档中都会有如下这样的提示：
为了将binlog数据保留足够长时间，用户可以选择自建binlog data store，来解决“里程”焦虑问题，但引入了额外的开发和运维成本。而在使用PolarDB-X时，在“无感消费”和“连续消费”的双重加持下，完全不用担心“里程”焦虑，这就是云原生的魅力——透明、简单。
最后，如何开启透明消费？ 如果使用的是商业版的PolarDB-X，binlog的透明消费能力是默认开启的，开箱即用；如果使用的是开源版的PolarDB-X，则需要手动开启，启动方法也很简单，拉起实例后按序执行如下SQL：
--目前支持两种备份存储，OSS 和 LINDORM --如果选择使用OSS，则执行如下命令： stop master; set global cdc_binlog_backup_type=OSS; set global cdc_oss_endpoint=xxx; set global cdc_oss_bucket_name=xxx; set global cdc_oss_access_key_id=xxx; set global cdc_oss_access_key_secret=xxx; start master; --如果选择使用LINDORM，则执行如下命令： stop master; set global cdc_binlog_backup_type=LINDORM; set global cdc_lindorm_endpoint=xxx; set global cdc_lindorm_thrift_port=xxx; set global cdc_lindorm_s3_port=xxx; set global cdc_lindorm_bucket_name=xxx; set global cdc_lindorm_access_key_id=xxx; set global cdc_lindorm_access_key_secret=xxx; start master;
多流Binlog
问：PolarDB-X最多可以有多少DN节点？
答：理论上无上限。目前我们做过的最大规模的测试规模是1024个节点，参见《分布式1024节点！1天玩转PolarDB-X超大规模集群》
问：PolarDB-X最多可以有多少CDC节点？
答：理论上无上限。但全局binlog(单流)存在单点瓶颈问题，无法通过增加节点达到线性扩展的目标，如：当DN数量不断膨胀时，全局binlog(单流)的延迟可能会不断增大；或者，即使全局binlog自身不存在性能瓶颈，但下游消费程序可能早已触达“天花板”。
问：PolarDB-X如何破解全局binlog(单流)的单点瓶颈问题？
答：PolarDB-X的数据表可以分区并分布在多个DN节点上，binlog日志流亦可分区并分布在多个CDC节点上，这就是PolarDB-X提供的多流binlog，具体介绍可参见官网介绍。
问：PolarDB-X的多流binlog适用于什么规模的实例？
答：多流binlog适用于什么规模的实例，并没有一个确切的答案，随着DN节点数量和写入流量的不断增大，单流复制链路触达瓶颈的可能性会越来越大，并且，首先会触达性能瓶颈的往往是下游消费程序，而不是binlog。一般来说，DN节点数量小于等于50个时，不管流量大小，生成binlog的延迟都可以控制在500ms以内，每分钟最高可生成70个左右的binlog文件(每个binlog文件的大小500MB)。
问：PolarDB-X的多流binlog使用门槛高不高？
答：全局binlog(单流)提供了完全兼容MySQL的使用体验，多流binlog同样采用了高度兼容MySQL的使用体验，具体介绍可参看官网介绍。概括来说，不管是单流binlog，还是多流binlog，针对每条日志流，PolarDB-X能够做到完全兼容MySQL的使用体验。
AS Master As MySQL
As MasterS As MySQL
注意：这里多了一个S，一条流就是一个Master，一个PolarDB-X实例就是Master的超集
双重身份
基于PolarDB-X CDC的binlog，不仅可以配置PolarDB-X和MySQL之间的数据复制，还可以配置PolarDB-X和PolarDB-X之间的数据复制。针对前者，PolarDB-X的身份是MySQL，针对后者，PolarDB-X的身份是它自己。
那么，问题来了，如果在PolarDB-X执行一条这样的SQL，在binlog中该如何复制?
create table t1( a int primary key, b int, c int, d varchar(10), global index (b) partition by key(b) partitions 2, unique global index g2(c) partition by key(c) partitions 2, unique global key g3(c) partition by key(c) partitions 2, global unique index g4(c) partition by key(c) partitions 2, global unique key g5(c) partition by key(c) partitions 2) partition by key(a) partitions 3
如果将该SQL原样输出到binlog，则会导致下游MySQL复制报错，因为MySQL无法识别该sql中PolarDB-X特定的语法(global index ...)；如果把SQL中PolarDB-X特定的语法剔除，则会导致下游PolarDB-X无法完整重放上游PolarDB-X的ddl操作。 对应的解决方案很朴素但很有效：剔除ddl sql中PolarDB-X的特有语法，将sql转化为和单机MySQL兼容的形态并输出，供单机MySQL和相关同步工具使用，同时将原始SQL以注释的方式附加到输出内容中，供PolarDB-X使用，如果某个sql形态是PolarDB-X独有的，则只输出注释形态的sql即可。如下所示：
孪生兄弟
PolarDB-X支持两地三中心部署形态，如下图所示，具体介绍可参见官网介绍。
在两地三中心部署形态下，一个核心的技术挑战便是数据的跨地域复制，面对跨地域网络30ms的RTT，如何最大限度的保证数据的传输速度来降低RPO？常见的手段有：
- 对数据进行压缩传输 这是一个比较常见的手段，通过压缩来降低网络传输的数据量，比如MySQL便提供了相应能力，配置数据复制时，合理配置MASTER_COMPRESSION_ALGORITHMS 和MASTER_ZSTD_COMPRESSION_LEVEL便可开启压缩传输，具体可参见官网介绍。压缩肯定是可以降低带宽消耗的，但压缩本身也比较耗时，对于数据复制的延迟时间可能会带来负面影响，比如假设压缩100MB的数据消耗5s，但5s内可以传输200MB的数据，此时压缩让数据传输变得更慢了。因此，在不同场景下，需要结合网络带宽、网络RTT、数据的增长速度、压缩的速度、对延迟的要求等因素综合考虑压缩策略。
- 增加数据复制的并行度 在网络带宽充足的情况下，增加数据传输的并行度，可以有效提升数据的传输速度，来抹平网络延迟带来的传输瓶颈。在这方面，比较典型的一个案例是Alibaba Otter，为了解决中美机房之间跨大洲传输的瓶颈问题，Otter采用了“在发送端并行发送数据，在接收端重新串行化排序”的策略，来增加单位时间内网络上“在途”的数据报文的数量，参见Otter调度模型。
- 产品层面的定制化优化 如协议优化等
PolarDB-X在两地三中心部署形态下，DN节点之间会涉及跨地域的paxos协议数据传输和binlog数据传输，不同的DN集群之间是并行传输的，每个DN集群的数据传输也支持压缩等机制，能够较好的满足低延迟复制的需求。除了DN之间的复制，主实例和异地备实例之间的数据复制，也是必不可少的一环，该复制需要基于PolarDB-X CDC提供的全局binlog来完成，此时对CDC便提出了更高的要求：
- CDC的节点需要分布在两个地域的每个机房，以保证高可用能力
- CDC全局binlog数据需要在两个地域都有冗余备份，以保证任一地域不可用时，其它地域可正常提供服务
- PolarDB-X异地备实例，应该优先从本地域消费全局binlog，以达到更低的延迟
面对如上需求，有两种实现思路。一种思路是直接增加CDC节点数量，CDC节点部署到每个机房，便可满足需求1；依托CDC自身提供的跨节点binlog复制能力，便可满足需求2；引入机架感知能力，进行适当改造，便可以满足需求3。如下图所示：
策略一, 复制模式.drawio.png
上述方案，较容易触发跨地域数据传输的性能瓶颈，由于全局binlog(单流)汇总了所有DN的binlog数据，单链路跨地域传输不是一个理想选择，即使引入压缩能力，但短板仍然很明显，通过下面的测试案例可以有更直观的感受。 1）准备两台ECS，记做A和B，如下所示
因要构建大量binlog，购买实例时，磁盘规格要设置高一些，不要让磁盘成为测试瓶颈，本测试没有加额外的数据盘，选用系统盘的规格为(ESSD，500GB+PL2) ，最大吞吐为370M/s左右
2）通过pxd，拉起一套polardbx测试实例
- 需保证该实例的CDC集群在A和B上都有节点，Dumper的复制方向为A到B，拓扑配置文件示例见附录
- 拉起集群后，需要将binlog_purge_enabled 参数配置为false，关闭自动清理binlog文件功能
3）在A上进行tpcc或者sysbench测试，构造大量binlog文件 可以选择多跑几次tpcc测试，先构建出足够多的binlog文件，然后将B上的binlog文件清空，从000001开始复制，观察bps指标
4）构造不同的网络延迟环境，观测A和B之间dumper的同步性能情况 模拟延迟的方法，在A上执行如下命令：tc qdisc add dev eth0 root netem delay xxms (多次执行，把add替换为replace)，通过ping命令可以验证是否生效，如下所示：
5) 测试结果如下 说明: 在不同PolarDB-X版本、不同环境、不同TCP协议参数下，得到的数据可能是有较大差异的，主要关注不同网络延迟条件下，数据复制吞吐能力的变化趋势即可。
所以，靠简单增加CDC节点数量的方式来满足两地三中心的要求，不是一个理想的选择。
新的思路：理论上一个PolarDB-X实例可以拥有无限多个CDC集群，在异地拉起一个独立的CDC集群、基于异地的DN节点、构建一份独立于中心地域的全局binlog，即不需要跨地域传输全局binlog数据，直接基于异地DN的物理binlog就地生成一份全局binlog供异地就近使用。 而多集群能力恰恰是CDC在设计之初，就为未来的扩展性预设的基础能力，CDC绝大部份的元数据表都预设了cluster_id字段，来支持多套集群同时运行。
具体来说，PolarDB-X上可以提供无限多个单流binlog集群和多流binlog集群，不仅如此，PolarDB-X的Columnar集群和Replica集群，也是被CDC的多集群能力来纳管的，扩展起来非常方便。不同地域部署独立的binlog集群，如下所示：
两个地域的CDC集群遥相呼应，可以生成相同的全局binlog文件，但却互不干扰，就像一对孪生兄弟，虽然模样相同，但有各自独立的人生。此时此刻，想起了唐代诗人李之仪的诗句：
我住长江头， 君住长江尾， 日日思君不见君， 共饮长江水。 在PolarDB-X场景下翻译过来就是 我在上海机房， 君在重庆机房， 日日使用相同的元数据表，却彼此看不到对方， 我们消费相同的物理binlog副本，奔向各自的方向。
结语
本文对PolarDB-X CDC的一些高阶能力进行了汇总介绍，但这绝不是PolarDB-X CDC的终态，追求简单易用、生态兼容、灵活扩展并借助云的优势为用户提供好用的功能是我们孜孜不倦的追求。基于CDC提供的两个基础能力binlog和replica，我们正在打造原生的跨地域容灾以及多云容灾能力——GDN，即将上线，敬请期待。
附录
Pxd配置文件示例
version: v1 type: polardbx cluster: name: pxc_test gms: image: polardbx/polardbx-engine:latest host_group: [172.16.0.236] resources: mem_limit: 16G cn: image: polardbx/polardbx-sql:latest replica: 1 nodes: - host: 172.16.0.236 resources: mem_limit: 32G dn: image: polardbx/polardbx-engine:latest replica: 2 nodes: - host_group: [172.16.0.236] - host_group: [172.16.0.236] - host_group: [172.16.0.236] resources: mem_limit: 32G cdc: image: polardbx/polardbx-cdc:latest replica: 2 nodes: - host: 172.16.0.236 - host: 172.16.0.235 resources: mem_limit: 16G
