简介：尚硅谷研究院编写的Flink CDC 3.0学习文档，面向已有一定Flink基础、关注大数据实时同步与流式ETL的研发人员，聚焦MySQL数据实时捕获并同步至Doris的完整流程。文档从CDC概念入手，对比基于查询与基于Binlog两类实现方式的区别，进而介绍flink-cdc-connectors组件的原理与用法，帮助读者理解全量加增量的数据读取机制。实操部分覆盖MySQL到Doris的Streaming ETL全链路，包含多库多表数据准备、DataStream与Flink SQL两种开发方式、环境搭建、配置文件编写、任务启动及测试，并强调开启Binlog、设置检查点等关键配置，确保同步低延迟、高可靠与数据一致性。文档还细致演示了test与test_route两个数据库下的多表同步配置，帮助理解数据路由与表匹配策略；完整代码和操作步骤可直接参考，适合在实际项目中按需调整参数。压缩包为一个docx文档，大小145KB，已有1788人学习下载。
1. Flink CDC 3.0 + Doris：一条YAML打通的MySQL实时数仓链路
在订单、用户行为、IoT上报这类大数据技术场景里，从线上MySQL把数据实时同步到Doris，几乎是每支数据团队都绕不开的硬需求。早期方案常是Canal监听binlog再自研写入逻辑，每次加字段、改类型都要跟着改代码，表一多维护成本直接失控。Flink CDC 3.0把全量快照、增量binlog监听、Schema演进和Doris写入都封装成一条可配置的Pipeline，几十行YAML就能把一张表甚至整个库实时同步过去。这篇文章按一线落地流程来写：先讲CDC架构和binlog原理，再给一份能直接改着用的YAML配置，最后把生产环境真正会翻车的坑逐条拆开。适合正在选型实时同步方案，或者已经被Canal+自研方案折腾到想换思路的开发者。
2. 为什么是Flink CDC 3.0：从binlog到YAML Pipeline的架构演进
2.1 MySQL CDC的底层原理：binlog的角色与三种格式
CDC（Change Data Capture）要做的事情，用一句话概括就是“把数据库里的每一次数据变更变成流”。在MySQL场景里，这个事件流的唯一可靠来源是binlog。只有开启了binlog并选择了正确的格式，才能拿到每一行INSERT、UPDATE、DELETE的前后镜像。binlog有三种格式：STATEMENT只记录SQL语句本身，ROW记录每行变更前后的完整值，MIXED是前两种的混合策略。CDC场景必须选ROW，因为Doris端做更新时，要有完整的前值去做主键匹配和列级更新。
上线之前我习惯花一分钟确认源库的四个关键变量，命令如下：
SHOW VARIABLES LIKE 'binlog_format'; SHOW VARIABLES LIKE 'log_bin'; SHOW VARIABLES LIKE 'binlog_row_image'; SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';参数说明：第一条确认binlog格式是否为ROW，第二条确认binlog总开关，第三条很关键——如果binlog_row_image被设置成MINIMAL，binlog里会省略未被更新的列，Flink CDC拿到的before镜像就是不完整的。第四个参数是binlog保留时长，在MySQL 8.0里默认大约30天，如果你所在业务的实例把它调得很短，而Flink作业刚好频繁重启，重启期间落下的binlog事件可能已经被清理掉，任务只能被迫重新做全量。
注意：
binlog_row_image=MINIMAL时，增量阶段拿到的before是裁剪过的，Doris端更新时只能覆盖部分列，一旦表里有默认值或触发器，两侧的列值就会逐渐对不上。我通常会显式设成FULL，不依赖实例默认值。
binlog_format在MySQL 8.0默认就是ROW，但很多5.7老实例默认还是STATEMENT，Flink CDC连接器对这种实例要么启动报错，要么同步出来的结果是错的。查一遍这几个参数，能省掉后面一整天的排查时间。
2.2 从2.x到3.0：增量快照与YAML Pipeline带来的变化
Flink CDC不是第一天才有。2.x时代最常见的使用方式是Flink SQL：用mysql-cdc连接器建一张Source表，再用Doris连接器建一张Sink表，跑一条INSERT INTO SELECT。这套方案能跑通，但有两个让人很别扭的硬伤。一是全量快照阶段会给源表加表锁，生产环境的大表不敢轻易做全量；二是每张表都要手工写建表语句和字段映射，五六十张表写下来全是重复劳动，换个环境还得再写一遍。
Flink CDC 3.0把这两件事推到了框架层解决。增量快照（Incremental Snapshot）算法把一张表按主键切成多个chunk，多个并行子任务分块读取，每个chunk只短暂持锁，对线上影响降到很低。YAML Pipeline则把Source、Transform、Sink封装成声明式配置，同一份配置能同时描述多张表，不用再逐表写SQL。开发者从“写代码”变成“写配置”，同步链路的可维护性高了一个量级，这也是很多团队从Canal方案切换过来的直接动力。
具体到同步体验，3.0还内置了自动建表能力。Doris Sink会根据源表Schema推导目标表结构，把MySQL主键映射成Doris的Unique模型，把字段类型翻译成Doris能识别的类型。我个人的使用感受是：2.x解决的是“能不能同步”，3.0解决的是“同步得好不好”，从全量加锁到增量快照、从手写建表到自动建表，每一步都在砍运维成本。
2.3 选型考量：什么场景该用这套链路，什么场景不该用
先说我推荐用的场景。一是实时数仓的ODS层建设，线上几十张业务表需要低延迟沉淀到Doris供下游分析使用；二是业务数据分析场景，订单、库存、用户状态有准实时查询诉求。这两类场景的共性是：目标端是OLAP引擎、源端以MySQL为主、表数量多、表结构会持续演化。
不推荐用的场景也要说透。目标端如果是事务型数据库、需要强一致事务语义，这套链路默认给的是最终一致性，需要额外设计补偿机制；源库如果是Oracle、PostgreSQL这类非MySQL引擎，连接器生态的成熟度不如MySQL，落地前要做更细的兼容性验证。还有一种情况是业务只需要每天跑一次全量同步，根本不需要CDC的常驻作业，用批处理工具凌晨跑一遍更省资源。
我在评估一个项目是否值得上这套链路时，会先看三个硬条件：源表是否都有清晰主键；binlog保留时长能不能覆盖一个完整的checkpoint恢复周期；Doris侧是否接受自动建表产生的物理模型。三个条件都满足，才值得投入人力做精细化调优。
2.4 版本组合与依赖规划：jar包放不对，万事皆休
Flink CDC 3.0不是一个独立服务，它是以Flink作业的形态运行的。依赖规划如果乱了，后面所有调试都会被拖进泥潭。一套常见且经过验证的稳定组合是Flink 1.18.x + Flink CDC 3.0.x + Doris 2.x。CDC发行包的版本号跟Flink版本有绑定关系，下载flink-cdc-dist-3.0.*.jar时要看清楚对应的Flink版本，别拿错。
依赖放哪里也有讲究。Pipeline模式下，flink-cdc-pipeline-connector-mysql和flink-cdc-pipeline-connector-doris两个jar包要放进Flink的lib目录，而不是作为作业的user jar提交。放错位置最常见的报错是ClassNotFoundException: org.apache.flink.cdc...，排查半天最后发现是jar放错目录。另外一个容易被忽略的点是Doris Sink底层走Stream Load的HTTP协议，Flink的TaskManager到Doris FE的8030端口网络要通，安全组别只放通3306就完事。
版本这块我的原则是“先固定、后升级”。生产环境用一套组合跑熟之后，非必要不动版本；升级CDC之前，先在测试环境把YAML同步用例整个跑一遍，确认checkpoint和DDL同步都正常再上生产。很多线上查到最后都是jar包版本混用的问题——Flink CDC 3.0和2.x的连接器API不兼容，不能混着放。
3. 最小闭环：用一份YAML把MySQL的单表实时推到Doris
3.1 部署前的准备：MySQL权限、Doris建库、Flink依赖
动手之前先把资源准备好。假设你已经有一套能用的Flink集群、一个MySQL实例和一个Doris集群。MySQL侧除了确认binlog状态，还要建一个专用的同步账号，权限要一次给够：
CREATE USER 'flinkcdc'@'%' IDENTIFIED BY 'your_password'; GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'flinkcdc'@'%'; FLUSH PRIVILEGES;权限说明：SELECT用于全量快照阶段读取表数据；REPLICATION SLAVE和REPLICATION CLIENT用于消费binlog；RELOAD和SHOW DATABASES用于CDC框架动态发现数据库列表和获取位点。少了RELOAD权限，作业启动阶段会报一个权限不足的错误，这个报错信息藏得比较深，很容易被误判成网络问题。
Doris侧只需要提前创建好目标数据库，表可以交给Sink自动创建。用Doris的MySQL协议执行一行语句：
CREATE DATABASE IF NOT EXISTS ods_db;Flink侧的操作是把三个jar包放进$FLINK_HOME/lib目录并重启集群：
cp flink-cdc-dist-3.0.x.jar $FLINK_HOME/lib/ cp flink-cdc-pipeline-connector-mysql-3.0.x.jar $FLINK_HOME/lib/ cp flink-cdc-pipeline-connector-doris-3.0.x.jar $FLINK_HOME/lib/关于jar包有一条血泪经验：CDC 3.0和2.x的连接器jar不能共存，替换前先把旧jar清理干净，不要图省事直接覆盖。很多ClassNotFound的根因就是lib目录里残留了旧版连接器，两个版本的类名冲突，Flink加载到哪个全看运气。
3.2 第一份YAML配置：每一行参数是干什么的
下面这份配置是我在一个模拟项目X里实际跑通过的最小配置，同步biz_db.orders这张订单表到Doris的ods_db库：
source: type: mysql hostname: 192.168.1.100 port: 3306 username: flinkcdc password: your_password tables: biz_db.orders server-id: 5400-5404 properties.serverTimezone: Asia/Shanghai sink: type: doris fenodes: 192.168.1.200:8030 username: doris_user password: doris_password database: ods_db table: create-if-not-exists: true pipeline: name: mysql-orders-to-doris parallelism: 2逐段说明。source.tables支持精确的库表名，也可以写成biz_db.*把整个库纳入管道。server-id是Flink CDC以MySQL从库身份注册复制流时使用的ID，写成范围5400-5404的意思是给这个作业预留5个ID。并行度大于1或者同一实例下表数量多时，server-id一定要给够，否则多个并发抢同一个ID，MySQL会不断踢掉旧连接。properties.serverTimezone是透传给底层JDBC的时区参数，不写这个，后面大概率会踩到8小时时区偏移。
sink.fenodes填Doris FE节点的HTTP端口地址，多个FE用逗号分隔。database是Doris目标库名，必须提前手工创建，Sink不会帮你建库，它只负责建表。create-if-not-exists开启后，Sink会按源表字段自动推导建表语句，自动把主键映射成Unique模型，副本数和分桶数也自动生成。如果你对Doris表模型有特殊要求，比如要指定分区粒度或副本数，可以先手工建表，再把这个开关关掉。
pipeline.parallelism决定整条管道的并行度。并行度不是越大越好，它同时受server-id数量、MySQL实例压力、Doris导入能力三方约束。见过有人直接设16，结果源库连接数被打满，全量阶段反而更慢。合理的起点是2到4，观察延迟和背压再逐步往上加。
3.3 提交任务与三步验证法：确认数据真的过去了
配置保存为mysql-to-doris.yaml后，在Flink集群上提交：
bin/flink run \ --no-detached \ -D execution.checkpointing.interval=10s \ -D execution.checkpointing.mode=EXACTLY_ONCE \ /path/to/mysql-to-doris.yaml命令说明：--no-detached让作业在前台运行，方便直接看日志。两个-D参数设定checkpoint间隔和一致性语义。CDC的断点续传严格依赖checkpoint，这类同步作业一定要开checkpoint，间隔10到30秒是常见区间。间隔太短，状态后端写入压力大；间隔太长，故障恢复时要回放更多binlog，追平延迟的时间变长。
提交之后做三步验证。第一步，看Flink日志，确认作业从Snapshot阶段切入Binlog阶段，说明全量先跑完了，增量已经接上。第二步，登录Doris确认表自动创建成功，并核对全量行数：
SHOW TABLES FROM ods_db; SELECT COUNT(*) FROM ods_db.orders;第三步，在MySQL侧执行一条更新，几秒后回到Doris查同一个主键：
UPDATE biz_db.orders SET status = 2 WHERE order_id = 100001; SELECT order_id, status FROM ods_db.orders WHERE order_id = 100001;如果status没变，先看日志有没有报错，再看Doris表的模型和主键是否跟MySQL一致。如果status变了但值不对，优先怀疑时区、类型映射或者字段顺序。这三步验证每次接入新表都值得跑一遍，链路通了，后面照着复制就行。
4. 全量与增量如何衔接：快照分块、位点恢复与DDL同步
4.1 增量快照算法：为什么全量阶段不再长时间锁表
表数量多、单表数据量大时，全量快照是第一个性能瓶颈。Flink CDC 3.0的增量快照算法把一张表按主键区间等分成若干个chunk，每个chunk由不同的并发子任务去读取。读每个chunk之前，先获取当前的binlog位点，读完之后把位点一并记录到checkpoint。所有chunk读完后，再统一回放快照期间产生的binlog变更，把增量数据补齐。
这个设计的精髓在于锁粒度。2.x时代的全量阶段用一次SELECT * FROM table带着全局读锁，生产大表跑全量会卡住其他事务。3.0的chunk读取走的是InnoDB快照读，持锁时间只覆盖单个chunk的查询，对线上影响小到可以忽略。所以全量和增量两个阶段并不像表面看起来那样严格割裂，而是通过binlog位点无缝衔接。
分块有个硬前提：表必须有主键。没有主键的表，Flink CDC会降级成单并发整表扫，锁行为回到2.x的状态，增量阶段的精确一次语义也无法保证。所以我在选型阶段就要求“源表必须有主键”，这不仅是同步链路的要求，也是数据质量的基本底线——没有主键的表在Doris里建Unique模型时也没有抓手。
4.2 Checkpoint里存了什么：断点续传的位点恢复细节
Flink作业崩溃后恢复，CDC到底从哪里继续读？答案就在checkpoint的状态里。状态里同时存了两类信息：一类是chunk读取进度，已经完成的chunk不会重读；另一类是binlog位点，精确到读到了哪个binlog文件的哪个offset。任务重启后从最近一次成功的checkpoint恢复，已完成chunk的数据不再重复读，未完成chunk从记录位点继续读，binlog变更从记录的位置继续消费。
这个机制能成立，依赖几个外部条件。第一，binlog保留时长必须大于“故障时长加恢复时长”之和，否则位点对应的binlog文件已被清理，只能放弃位点重新做全量。第二，server-id必须全局唯一，如果两个作业用同一个ID去连同一个MySQL实例，binlog位点的维护会互相干扰，表现就是任务随机报错且难以复现。第三，checkpoint本身必须稳定成功，如果状态后端写得很慢导致checkpoint一直失败，CDC的“续传”就失去了锚点。
状态后端的选择也会影响恢复速度。作业状态如果很大，默认的HashMap状态后端放在内存里容易溢出，我一般换成RocksDB并开启增量checkpoint，恢复时虽然稍微慢一点，但稳定性明显更好。这里没有放之四海皆准的答案，唯一的标准是：在测试环境手动杀掉一个TaskManager，看恢复时长是否在业务可接受的延迟范围之内。
4.3 Schema演进：DDL同步的能力边界
业务侧加字段几乎天天发生，如果每次加列都要停任务、改代码、重跑，这套链路就没有长期使用的价值。Flink CDC 3.0支持把MySQL端的DDL解析成Doris语义并在目标端自动执行。我在模拟项目里实际验证过几种常见的DDL，结果整理成一张表：
| MySQL端操作 | Doris端行为 | 备注 |
|---|---|---|
| ADD COLUMN加列 | 自动加列 | 最常用，基本可用 |
| MODIFY COLUMN改类型 | 尝试同步变更 | 类型不兼容时会失败 |
| DROP COLUMN删列 | 受策略管控 | 默认可能直接忽略 |
| RENAME TABLE重命名表 | 不支持 | 需要规避这类源端操作 |
DDL失败时的行为由一个策略参数控制，就是pipeline段的schema-change-policy，常见取值有两个：lenient表示DDL同步失败只记日志，任务继续跑；exception表示任何DDL同步失败都让任务直接失败。生产环境我一般先开lenient观察几天，确认哪些DDL不受支持之后，再考虑是否收紧。一上来就开exception的风险是，某次不受支持的ALTER TABLE直接把整条管道搞挂，业务数据全部停更。
这里还需要理解一个关键点：Doris的同步不是把MySQL的DDL原封不动搬过去，而是翻译成Doris模型能识别的语义。比如MySQL的字段类型和字符集到了Doris侧要做相应的映射，分区和分桶策略也未必能一一对应。所以“DDL同步”不等于“零手工”，核心表的物理模型我依然建议人工把控。如果MySQL端DDL比预想中频繁，比如每天都有alter table，我建议把DDL相关日志单独落到文件里，定期观察哪些操作被Doris正确翻译、哪些被忽略，积累一份DDL黑白名单，让源端变更从一开始就避开雷区。
5. 生产环境避坑指南：同步链路最常见的六个翻车点
5.1 server-id冲突：任务跑着跑着突然被源库断开
现象：作业启动后的前几分钟一切正常，运行一段时间后，Flink日志里出现连接重置错误，或者源库侧出现大量aborted连接，任务反复重启，恢复后又会重演。
原因：server-id配置写成了单一值5400而没写成范围，作业并行度又是4，4个并发子任务向MySQL注册复制流时用了同一个ID，MySQL把这当成了非法连接，不断踢掉先前的连接。另一个常见来源是两个同步作业共用了同一个ID区间。
解决：把server-id写成起止范围，并且范围长度要大于等于并行度。比如并行度4，就写5400-5407。多个作业之间也要像分配端口一样规划好ID区间，绝对不能重叠。这个参数是最容易被忽略、踩中后最难排查的，它属于典型的“玄学故障”——不是必现，而是并发一高才现。
5.2 时区偏移8小时：数据没丢但全部对不上
现象：MySQL里的DATETIME字段同步到Doris后，比源库时间小8小时或者大8小时，其他字段一切正常。更新一条记录后，Doris里的时间字段依旧偏移，不是个例，是全表都偏。
原因：Flink CDC在解析binlog里的TIMESTAMP类型时，默认按UTC处理；JDBC连接没指定serverTimezone时，驱动又按JVM所在机器的默认时区解析，两边各转一次，结果就是整体偏移8小时。
解决：在YAML的source段显式声明时区参数：
source: type: mysql ... properties.serverTimezone: Asia/Shanghai同时把Doris FE和BE的time_zone参数也统一掉，两边一致才不会有累计偏移。这条要在上线前就验证掉，因为已经写错的偏移数据不会自动纠正，只能重新校准或重跑。
5.3 无主键表更新错位：Doris里出现多行重复
现象：源表没有主键，业务在MySQL执行UPDATE，Doris里不但没更新，反而多了几行；按业务ID查询能查到多条记录，聚合结果看起来像翻倍。
原因：自动建表把无主键源表映射成了Doris的Duplicate模型。Duplicate模型只追加不更新，每次变更都变成新行写入，这是目标端表模型决定的，不是CDC传输的问题。
解决：源端能加主键就加主键，这是治本的办法。源端实在不能加，就在Doris手工建表，挑一个业务上近似唯一的字段作为UNIQUE KEY，同时把create-if-not-exists关掉。注意，自动建表不会替你做逻辑判断，它对无主键输入只会产出最基础的模型，期望它做出合理选择是不现实的。
5.4 大事务把任务打挂：max_allowed_packet不足
现象：某天凌晨业务跑批更新了几十万行数据，同步任务突然报Packet too large错误，连接被源库断开，任务进入重启循环。白天业务正常时任务又是好的，非常典型的间歇性故障。
原因：Flink CDC消费binlog本质上也是一个MySQL客户端，单条binlog事件可以很大。客户端默认的max_allowed_packet如果小于事件体量，连接就会被源库强制断开。这个限制在客户端和源库两侧都要过一遍，只调一边没用。
解决：在YAML的source段增加连接参数：
source: type: mysql ... properties.max_allowed_packet: 134217728同时确认MySQL侧的max_allowed_packet不小于这个值，两边同步放宽才有效。上线前建议先了解一下业务是否有时段性大事务，比如定期的批更新或清洗任务，如果有，提前把两边都调好，别等被打挂再来救。
5.5 Doris写入背压：Sink频繁重试导致延迟雪崩
现象：任务一直跑但不报错，延迟从几秒一路涨到几十分钟。Flink UI里Doris Sink的背压显示为HIGH，日志里频繁出现stream load error或者HTTP 500。
原因：Doris Sink底层通过Stream Load写入，每个批次都要跟BE建HTTP连接。当Doris的导入并发达到上限，或者FE/BE节点网络不稳定，Sink就会反复重试；重试又占住更多的连接资源，背压一层层传到Source端，整个管道的数据越积越多。
解决：先扩容Doris或调整导入并发，再从Sink参数上做优化。常见做法是调整重试次数和攒批字节数：
sink: type: doris ... sink.max-retries: 10 sink.buffer-size: 8388608重试次数提高失败容忍度，攒批字节数加大以后减少HTTP请求频率。但buffer-size不是越大越好——单批次过大会让Stream Load本身超时，反而加剧重试。我的做法是从默认值出发，每次调大10%到20%，观察背压和Doris导入成功率，找到那个平衡点。
5.6 字符集乱码：中文全部变成问号
现象：Doris里查询同步过来的表，中文内容全是???或者乱码，英文和数字正常。源端MySQL表本身是utf8mb4，看起来没有任何问题。
原因：自动建表把字段默认字符集映射成了utf8，这里的utf8在Doris语境里对应的是utf8mb3，存不了emoji以及部分生僻汉字，中文字符在写入时要么被截断，要么被转码成错误字节。
解决：对字符敏感的正式表，在Doris侧手工建表并显式指定字符集，同时把create-if-not-exists设成false，让自动建表机制把控制权交回来。快速验证环境可以继续用自动建表，但生产环境的字符集、分区、副本数这些核心参数，建议始终掌握在DBA手里。
6. 从能跑到跑稳：一致性校验与调优检查单
6.1 五分钟一致性校验
链路跑通之后，最担心的就是数据悄悄对不上。我有一套轻量校验法，全量阶段结束后，在MySQL和Doris两侧各跑一次聚合，比对行数和checksum：
-- MySQL侧 SELECT COUNT(*) AS c, SUM(CRC32(CONCAT(order_id, '-', status, '-', amount))) AS chk FROM biz_db.orders; -- Doris侧 SELECT COUNT(*) AS c, SUM(CRC32(CONCAT(order_id, '-', status, '-', amount))) AS chk FROM ods_db.orders;两组数字一致，说明行数和关键字段值基本对得上。这个校验做不到逐行级别的严格比对，但能快速暴露漏数据、重复行、脏值这三类最常见的问题，性价比非常高。增量跑一段时间后，再挑几条新变更的数据重跑一遍，确认增量也没有问题。
6.2 性能调优的四个旋钮
第一是并行度，它受server-id数量和源库连接数限制，不是越高越快。第二是scan.incremental.snapshot.chunk.size，只影响全量阶段速度，调大能加快快照，但单chunk处理时间会变长，checkpoint间隔也要跟着放宽。第三是Doris Sink的buffer-size和max-retries，影响写入吞吐和失败容忍度。第四是checkpoint间隔，直接影响故障恢复速度和状态存储开销。
| 参数 | 调整方向 | 建议起点 | 主要影响 |
|---|---|---|---|
| parallelism | 受源库压力约束 | 2到4 | 吞吐上限 |
| chunk.size | 全量阶段调大 | 8096到16384 | 快照时长 |
| sink.buffer-size | 观察背压微调 | 4MB到16MB | Doris导入频率 |
| checkpoint间隔 | 平衡恢复时长 | 10到30秒 | 故障回放量 |
这四个旋钮是联动的，不要只调一个。最常见的问题就是单独把并行度调得很大，其他三个参数没跟上，结果源库被打满，全量反而更慢。
6.3 上线前检查单与我的收尾习惯
每次接入新表，我走一遍固定的检查单：binlog已开启且格式为ROW；同步账号权限完整；server-id不与其他任务重叠；时区参数已声明；源表有主键；Doris目标库已建好；DDL策略按实际需求配置。全部确认完，才提交作业。
这套链路用久了，我最大的感受是：CDC项目不是上线就完事的。最典型的翻车场景是任务跑了一周后，被凌晨某个大事务打挂，而凌晨没人值守，等早上看到告警时数据已经滞后了五六个小时。所以告警和自动恢复脚本一定要提前配好，checkpoint失败率、同步延迟、源库连接数三件事纳入值班监控，才算真正把链路收口。希望这篇笔记能帮你避开我踩过的这些坑，落地顺利。
本文还有配套的精品资源，点击获取
