PolarDB-X CDC之"兼容MySQL,高于MySQL"

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
云原生数据库 PolarDB 分布式版,标准版 2核8GB
简介: 本文主要介绍一下PolarDB-X在CDC能力上那些高阶能力。

作者:自扬


列夫·托尔斯泰曾说“艺术源于生活,并高于生活”,他认为艺术不仅仅是生活的简单复制,而应该能够表达更深层次的意义和价值,从而达到“高于生活”的境界。PolarDB-X作为一款兼容MySQL的云原生分布式数据库,我们的目标也不仅仅是简单的兼容MySQL,而应该借助云原生的优势、分布式的扩展性优势做更深层次的能力演进,从而达到“超越MySQL”的境界,称之为“兼容MySQL,高于MySQL”。本文主要介绍一下PolarDB-X在CDC能力上那些高阶能力。

CDC Review

对PolarDB-X CDC不熟悉的同学,可以参考我们的知乎历史文章,奉上链接

透明消费

冷热数据的无感消费

4.1.jpg


PolarDB-X的CDC集群会优先把构建好的binlog文件保存在本地磁盘,并支持实时上传到远端存储(例如OSS)。本地磁盘上的文件(可以称之为热文件)一般存活周期较短,远端存储上的文件(可以称之为冷文件)存活周期较长(例如15天)。针对远端存储上的文件,CDC提供了透明消费能力,即屏蔽了本地和远端的存储差异,下游系统无需为访问远端存储上的binlog数据做任何额外适配。 直观的举例: 登录PolarDB-X的CDC节点,进入/home/admin/binlog目录,可以看到编号小于65的binlog文件,已经归档到OSS


4.2.jpg

本地binlog文件

4.3.jpg

归档到OSS的binlog文件


在Polardb-X 命令行执行show binary logs,小于65的文件仍然可见;执行show full binary logs,还可以显示每个binlog文件的详细信息:binlog event的开始时间和结束时间、binlog文件的上传状态、存储状态等


4.4.jpg

通过mysqlbinlog工具,可透明消费已经归档到OSS的文件,通过show binlog events,亦可

4.5.jpg

4.6.jpg

并且透明消费,还可以有不错的消费速度,超过200MB/s的吞吐

4.7.jpg

除此之外,我们还提供了内置的「SQL闪回」能力,选定需要闪回的时间段,不管binlog文件是在本地,还是已经归档到OSS,抑或是同时跨越了本地和归档,只要文件还存在,可以进行快速闪回,满足「数据修复」和「数据审计」等需求。打个广告:免费使用哦 ^_^


4.8.jpg


始终如一的连续消费

MySQL的主从复制存在一个令人“恼火”的设计:支持基于binlog_file_name + binlog_file_position 开始进行消费,但不能保证Master和Slave节点上binlog文件的连续性(即相同名字的binlog文件,在Master和Slave上对应的内容很可能是不一样的),那么,当发生主从切换时,下游消费程序便无法基于之前的位点继续消费,需要引入各种“额外”的协调机制,如:


  1. 基于全局管理者的协调机制


主要用在MySQL的HA方案中,典型产品如MHA,其能够监测整个MySQL集群中不同节点的binlog复制状态,当需要进行HA切换时,通过一系列的日志补偿机制和切换算法,基于新的binlog_file_name和binlog_file_position对节点之间的复制关系进行重建。此处不详述,贴图贴链接,感兴趣的读者可以进行深入研究。

4.9.jpg


  1. 基于时间戳的自动协调机制。

主要用在数据同步链路Auto Recovery的场景下,典型产品如Alibaba Canal,其同步任务中,可以配置MySQL集群的多个节点,当一个节点不可用时,可以自动切换到另一个节点,此时会面临binlog位点不一致的问题,canal提供了基于时间戳的回溯机制,通过遍历binlog文件,找到这样一个binlog文件位点,该位点对应的binlog event的时间戳比HA切换前的已消费event的时间戳要小,即通过重复消费一个时间范围内的binlog event来实现HA切换,以保证不丢数据,当然这种模式下因涉及重复消费,需要消费程序具备“幂等”机制。此处不详述,贴图贴链接,感兴趣的读者可以进行深入研究。

4.10.jpg

针对这个让人“恼火”的问题,MySQL在5.7版本,正式引入了基于Gtid的复制方案,来弥补基于binlog_file_name + binlog_file_position的缺点,靠全局不重复的Gtid来屏蔽不同节点上的binlog文件差异,在很大程度上缓解了复杂性。但这里面有个前提,必须通过直接连接MySQL服务进程进行binlog消费,才能享受到这个便利性,如果binlog已经被归档,则还是需要通过binlog文件名字来进行管理和操作。 而现实情况是,归档后的binlog文件很可能是不连续的(如:发生过HA切换、节点重搭、跨机变配等操作),比如下图所示,一个RDS MySQL的两个节点发生了跨机迁移,迁移之后两个新节点的binlog文件的编号重新从000001开始,并且新的000001文件和老节点最后一个binlog文件,还有一定时间范围的日志数据重合。

4.11.jpg


在上面这个场景中,如果有下游消费程序想从某个历史时间点开始消费binlog,则仍然要面对这种可能的“不连续”问题,属实很麻烦。而使用PolarDB-X的binlog,则完全不用担心此类问题,不论发生何种运维动作(升级、变配、重搭等等),PolarDB-X能始终如一的保持binlog文件的连续性,为下游消费程序带来“透明无感”的使用体验。

再也没有“里程”焦虑

在进行数据同步时,常见的操作流程为,从某个时间点开始进行全量数据迁移,当全量数据迁移完成后,基于全量迁移开始的时间点通过回溯binlog追增量数据。在某些基于“事件溯源”思想构建软件架构的场景下,往往希望从很早的一个时间点(甚至是起始时间)开始消费binlog,来构造出新的应用数据。如上两个场景,都有将binlog保留足够长时间的需求,比如在使用DTS迁移数据时,在产品文档中都会有如下这样的提示:

4.12.jpg


为了将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

4.13.png


As MasterS As MySQL

注意:这里多了一个S,一条流就是一个Master,一个PolarDB-X实例就是Master的超集

4.14.png


双重身份

基于PolarDB-X CDC的binlog,不仅可以配置PolarDB-X和MySQL之间的数据复制,还可以配置PolarDB-X和PolarDB-X之间的数据复制。针对前者,PolarDB-X的身份是MySQL,针对后者,PolarDB-X的身份是它自己。

4.15.jpg


那么,问题来了,如果在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即可。如下所示:


4.16.png


孪生兄弟

PolarDB-X支持两地三中心部署形态,如下图所示,具体介绍可参见官网介绍

4.17.jpg

在两地三中心部署形态下,一个核心的技术挑战便是数据的跨地域复制,面对跨地域网络30ms的RTT,如何最大限度的保证数据的传输速度来降低RPO?常见的手段有:


  1. 对数据进行压缩传输 这是一个比较常见的手段,通过压缩来降低网络传输的数据量,比如MySQL便提供了相应能力,配置数据复制时,合理配置MASTER_COMPRESSION_ALGORITHMS 和MASTER_ZSTD_COMPRESSION_LEVEL便可开启压缩传输,具体可参见官网介绍。压缩肯定是可以降低带宽消耗的,但压缩本身也比较耗时,对于数据复制的延迟时间可能会带来负面影响,比如假设压缩100MB的数据消耗5s,但5s内可以传输200MB的数据,此时压缩让数据传输变得更慢了。因此,在不同场景下,需要结合网络带宽、网络RTT、数据的增长速度、压缩的速度、对延迟的要求等因素综合考虑压缩策略。
  2. 增加数据复制的并行度 在网络带宽充足的情况下,增加数据传输的并行度,可以有效提升数据的传输速度,来抹平网络延迟带来的传输瓶颈。在这方面,比较典型的一个案例是Alibaba Otter,为了解决中美机房之间跨大洲传输的瓶颈问题,Otter采用了“在发送端并行发送数据,在接收端重新串行化排序”的策略,来增加单位时间内网络上“在途”的数据报文的数量,参见Otter调度模型
  3. 产品层面的定制化优化 如协议优化等


PolarDB-X在两地三中心部署形态下,DN节点之间会涉及跨地域的paxos协议数据传输和binlog数据传输,不同的DN集群之间是并行传输的,每个DN集群的数据传输也支持压缩等机制,能够较好的满足低延迟复制的需求。除了DN之间的复制,主实例和异地备实例之间的数据复制,也是必不可少的一环,该复制需要基于PolarDB-X CDC提供的全局binlog来完成,此时对CDC便提出了更高的要求:


  1. CDC的节点需要分布在两个地域的每个机房,以保证高可用能力
  2. CDC全局binlog数据需要在两个地域都有冗余备份,以保证任一地域不可用时,其它地域可正常提供服务
  3. PolarDB-X异地备实例,应该优先从本地域消费全局binlog,以达到更低的延迟


面对如上需求,有两种实现思路。一种思路是直接增加CDC节点数量,CDC节点部署到每个机房,便可满足需求1;依托CDC自身提供的跨节点binlog复制能力,便可满足需求2;引入机架感知能力,进行适当改造,便可以满足需求3。如下图所示:

4.18.jpg

策略一, 复制模式.drawio.png

上述方案,较容易触发跨地域数据传输的性能瓶颈,由于全局binlog(单流)汇总了所有DN的binlog数据,单链路跨地域传输不是一个理想选择,即使引入压缩能力,但短板仍然很明显,通过下面的测试案例可以有更直观的感受。 1)准备两台ECS,记做A和B,如下所示

4.19.png

因要构建大量binlog,购买实例时,磁盘规格要设置高一些,不要让磁盘成为测试瓶颈,本测试没有加额外的数据盘,选用系统盘的规格为(ESSD,500GB+PL2) ,最大吞吐为370M/s左右

4.20.jpg

2)通过pxd,拉起一套polardbx测试实例


  • 需保证该实例的CDC集群在A和B上都有节点,Dumper的复制方向为A到B,拓扑配置文件示例见附录
  • 拉起集群后,需要将binlog_purge_enabled 参数配置为false,关闭自动清理binlog文件功能



4.21.jpg

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命令可以验证是否生效,如下所示:

4.22.jpg

5) 测试结果如下 说明: 在不同PolarDB-X版本、不同环境、不同TCP协议参数下,得到的数据可能是有较大差异的,主要关注不同网络延迟条件下,数据复制吞吐能力的变化趋势即可。

4.23.jpg

所以,靠简单增加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集群,如下所示:

4.24.jpg

两个地域的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
相关实践学习
跟我学:如何一键安装部署 PolarDB-X
《PolarDB-X 动手实践》系列第一期,体验如何一键安装部署 PolarDB-X。
相关文章
|
1天前
|
关系型数据库 MySQL Linux
关系型数据库mysql的跨平台支持
【6月更文挑战第12天】
21 1
|
1天前
|
存储 SQL 关系型数据库
关系型数据库mysql的性能与灵活性
【6月更文挑战第12天】关系型数据库mysql的性能与灵活性
48 1
|
1天前
|
关系型数据库 MySQL Java
关系型数据库mysql的开源与授权
【6月更文挑战第12天】
21 3
|
1天前
|
关系型数据库 MySQL 数据库
实时计算 Flink版操作报错合集之下载了mysql的cdc的demo,在本地调试时,报错:找不到这个包,该怎么办
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
|
2天前
|
存储 关系型数据库 MySQL
关系型数据库中的MySQL
【6月更文挑战第11天】
55 4
|
3天前
|
SQL 监控 关系型数据库
实时计算 Flink版产品使用问题之使用mysql cdc配置StartupOptions.initial()全量之后就不增量了,是什么原因
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
7天前
|
消息中间件 关系型数据库 MySQL
Flink CDC 最佳实践(以 MySQL 为例)
Flink CDC 最佳实践(以 MySQL 为例)
|
9天前
|
DataWorks API 调度
DataWorks产品使用合集之在调度配置配置了节点的上游节点输出,没办法自动生成这个flow的依赖,该怎么操作
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
|
9天前
|
DataWorks 安全 关系型数据库
DataWorks产品使用合集之建了 polar 与clickhouse的数据源。为什么数据库这里总是mysql呢
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
|
12天前
|
关系型数据库 MySQL 分布式数据库
PolarDB产品使用合集之PolarDB-X是否支持MySQL的WITH AS语法
PolarDB是阿里云推出的一种云原生数据库服务,专为云设计,提供兼容MySQL、PostgreSQL的高性能、低成本、弹性可扩展的数据库解决方案,可以有效地管理和优化PolarDB实例,确保数据库服务的稳定、高效运行。以下是使用PolarDB产品的一些建议和最佳实践合集。

相关产品

  • 云原生分布式数据库 PolarDB-X
  • 云原生数据库 PolarDB