获课：xingkeit.top/6591/

Flink CDC 实战：MySQL 全量 + 增量同步至 ClickHouse

传统 T+1 批处理同步，在实时看板、即时风控面前早已力不从心。Flink CDC 凭借内置 Debezium 引擎，直接解析 MySQL binlog，把全量快照与增量变更融为一体，端到端延迟压至毫秒级。这套方案，正在成为 MySQL 到 ClickHouse 实时同步的终极答案。

一、核心原理：一条链路打天下

Flink CDC 的工作逻辑分两个阶段。

全量阶段：首次同步时，它将表按主键拆成多个 chunk 并行读取，同时记录 binlog 位置。对一个 2TB 的订单表做快照，业务完全无感知——因为不锁表、不停机。

增量阶段：全量完成后，Flink CDC 伪装成 MySQL 从库，通过主从复制协议持续监听 binlog，把 INSERT、UPDATE、DELETE 事件转换成 Flink DataStream，经流处理后直接写入 ClickHouse。

整个过程不需要 Kafka 中转。Flink CDC 2.4 版本更是将 Debezium 引擎深度集成，一条链路从 MySQL 直通 ClickHouse，架构复杂度砍半，延迟从秒级降至 800 毫秒以内。

二、MySQL 端配置：三个铁律

binlog 是这套方案的命脉。配置错一步，后面全白搭。

第一，binlog_format 必须是 ROW。 只有 ROW 模式才记录每行变更前后的完整值，STATEMENT 模式下一条 UPDATE 影响一万行，binlog 里只有一条 SQL，CDC 根本无法还原。

第二，binlog_row_image 必须是 FULL。 配合 ROW 模式使用，确保拿到变更前和变更后的完整数据，而非只记录被修改了哪些列。设成 MINIMAL，UPDATE 未覆盖所有列时就会丢字段。

第三，server-id 必须唯一且不冲突。 Flink CDC 把自己伪装成 MySQL 从库，每个并发任务都需要独立的 server-id。生产环境建议用 5400-5404 这种范围格式，按并行度分配，避免多任务冲突导致数据错乱。

改完配置重启 MySQL，用 SHOW VARIABLES LIKE 'binlog%' 验证：log_bin=ON、binlog_format=ROW、binlog_row_image=FULL，三项全过才算就绪。

三、ClickHouse 端设计：选对引擎是关键

CDC 同步会产生重复的 INSERT——全量一遍、增量更新又来一遍。如果用普通 MergeTree，数据直接膨胀。

必须用 ReplacingMergeTree 引擎。 它按 ORDER BY 字段去重，保留最新版本。配合一个版本字段（如 update_time），写入时带上时间戳，ClickHouse 在后台 merge 时自动保留最新记录。某电商平台实测：全量 50 万条订单同步后，ReplacingMergeTree 去重准确率 100%，而普通 MergeTree 重复率高达 37%。

批量写入也要调优：设置 max_insert_block_size=5000，开启 async_insert=1，吞吐量提升近 90%。

四、Exactly-Once：数据不丢不重的底牌

实时同步最怕两件事：数据丢失、数据重复。Flink CDC 用 Checkpoint 机制兜底。

设置 env.enableCheckpointing(30000)，每 30 秒做一次快照，配合 EXACTLY_ONCE 模式，故障恢复时从上一个 checkpoint 精确重放，一条都不丢、一条都不多。ClickHouse 端再用 ReplacingMergeTree 做最终去重，双重保险。

五、一句话总结

Flink CDC 把 MySQL 变成了一张"会自动更新的动态表"，ClickHouse 负责承接分析重任。全量靠分片并行、增量靠 binlog 监听、一致性靠 Checkpoint + ReplacingMergeTree。三板斧下去，实时数仓的最后一公里，彻底打通。