Flink CDC 数据同步实践：从单表到整库的端到端指南

使用 Flink CDC 将 MySQL 数据实时同步到数仓或数据湖时，最常见的三个问题是：Binlog 读取延迟持续升高、多作业部署时 Server ID 冲突导致数据丢失、全量与增量衔接阶段出现数据不一致。解决这些问题需要从 MySQL 服务端配置、Flink CDC 作业参数调优到 Sink 写入策略三个环节逐一排查。本文给出从单表同步到整库同步的端到端实战指南。

MySQL 服务端配置：被忽视的源头

Flink CDC 依赖 MySQL Binlog 实现增量同步，如果 MySQL 端配置不当，再好的 CDC 框架也无法保证实时性。

Binlog 必须开启且格式设置为 ROW 模式。在 MySQL 配置文件中确认 log_bin=ON、binlog_format=ROW、binlog_row_image=FULL。使用 SHOW VARIABLES LIKE 'binlog%' 验证配置生效。如果 binlog_row_image 设置为 MINIMAL，删除操作将无法获取被删除行的完整数据，导致下游数据不一致。

expire_logs_days 参数控制 Binlog 保留天数。Flink CDC 在全量读取阶段耗时较长，如果 Binlog 在全量完成前被清理，增量阶段将无法从正确的位置恢复，导致数据丢失或重复。建议将 expire_logs_days 设置为 7 天以上，对于大表全量扫描可能需要数小时的场景，设为 14 天更安全。

max_allowed_packet 参数默认值通常为 4MB，当业务表包含大字段（如 TEXT、JSON 类型）时，Binlog 事件可能超过此限制被截断。建议调整为 64MB 或更高。

Server ID 管理：多作业并发的硬约束

Flink CDC 的每个同步作业在消费 Binlog 时需要分配一个唯一的 Server ID。MySQL 的 server-id 参数范围是 1 到 2^32-1，但多个作业使用相同或重叠的 Server ID 范围会导致 Binlog 位点错乱，轻则数据重复，重则数据丢失。

当集群中部署了多个 Flink CDC 作业时，必须为每个作业划分不重叠的 Server ID 区间。例如作业 A 使用 5001-5010，作业 B 使用 5011-5020。在 Flink CDC 的 DataSource 配置中，通过 server-id 参数指定区间，格式为 5001-5010。

常见错误是多个环境（开发、测试、生产）共用同一个 MySQL 实例但未区分 Server ID，导致不同环境的 CDC 作业相互干扰。建议建立 Server ID 分配台账，按环境、作业名、表名登记已分配的区间。

在 Kubernetes 等弹性调度环境中，CDC 作业可能被重启并分配到不同节点。如果作业使用静态 Server ID，重启后可以继续从上次的位点读取。但如果不指定 Server ID，每次重启会随机分配，可能导致与仍在运行的旧实例冲突。因此强烈建议显式指定 Server ID。

全量与增量衔接：切换时机是关键

Flink CDC 的工作流程分为两个阶段：先全量扫描 MySQL 表的当前快照，再切换到增量模式消费 Binlog。两个阶段之间的衔接点（Snapshot 阶段开始时的 Binlog 位点）是数据一致性的核心。

Flink CDC 2.x 及以上版本通过在启动时获取一致的快照点来保证 Exactly-Once 语义。具体机制是：作业启动时记录当前 Binlog 的 File 和 Position，全量扫描完成后从该位点开始增量消费，确保不丢不重。

但在实际生产中，全量扫描耗时可能达到数小时（千万行级别的表），期间 MySQL 持续写入新数据。这些新数据既不在快照中，也尚未被增量阶段消费，存在短暂的数据不可见窗口。解决方案是开启 Flink CDC 的 Incremental Snapshot 功能，它通过分片并行读取和 Chunk Checkpoint 机制，大幅缩短全量扫描时间，同时在全量阶段就开始消费 Binlog，消除数据不可见窗口。

整库同步：从单表到全库

整库同步与单表的核心区别在于需要动态发现表结构变化。Flink CDC 的 MySQLSyncDatabase 模式监听整个 MySQL 库的 DDL 变更，自动创建流表并启动同步。配置时需指定 database-filter 和 table-filter 过滤系统表，设置 schema-change 为 true 启用 DDL 同步。当源端表数量超过 500 张时，建议按业务域拆分为多个作业，每个负责 100-200 张表。

Sink 写入策略：下游存储适配

不同下游存储需要不同的写入策略。同步到 Kafka 时，每行变更作为一条 JSON 或 Avro 消息发送，包含操作类型和时间戳。同步到 Hive 时需配置分区策略和文件合并参数，Hive 不支持行级更新，UPDATE/DELETE 需通过全量覆盖或 Merge 机制处理，建议使用分区提交机制在窗口结束时批量提交。同步到 Hudi 或 Iceberg 时可利用湖格式的 Upsert 能力实现行级更新，这是目前 CDC 实时入湖的推荐方案。

StreamWorks 原生支持 Flink CDC 实时采集能力，内置 Binlog 位点管理、Server ID 自动分配和全量增量无缝衔接，可显著降低端到端同步方案的搭建和运维成本。

性能调优：应对超大数据量

当源端 MySQL 表数据量超过 10 亿行时，全量扫描阶段的性能成为瓶颈。几个关键调优方向：增大 Flink 作业并行度，每个并行实例处理一个 Chunk 分片；调整 scan.fetch-size 参数控制每次从 MySQL 读取的行数，默认值为 1000，网络带宽充足时可提升到 5000；开启 Chunk Checkpoint 频率调整，减少全量阶段的检查点开销。

增量阶段的延迟优化重点在 Sink 侧。批量写入比逐行插入的吞吐量高 5-10 倍，通过 Flink 的 Mini-Batch 机制可以将多条变更合并为一次批量写入。同时监控 Flink 作业的反压指标，如果 Sink 端出现持续反压，需要增加 Sink 并行度或优化目标存储的写入性能。