Flink CDC MySQL 整库同步实战指南

企业数据架构正从离线批处理向实时数据管道演进，而 MySQL 整库同步是这一转型中最常见的起点。Flink CDC 3.x 引入的 Pipeline 架构彻底改变了传统做法——不再需要为每张表手写 DataStream 代码或 SQL 作业，只需一份声明式 YAML 文件，即可将数百张表的增量数据同步到 Doris、Paimon 或 Iceberg 等下游系统，并自动追踪 Schema 变更。本文从 Flink CDC 3.6 的 Pipeline 架构出发，覆盖整库同步的 YAML 配置、自动建表、Schema 演化以及生产环境中的关键注意事项。

为什么选择 Pipeline 架构

传统的 Flink CDC 整库同步需要开发者为每张表编写独立的 Source 和 Sink 代码，当表数量达到数百甚至上千张时，作业的开发和维护成本呈线性增长。Flink CDC 3.x 的 Pipeline 架构将整库同步抽象为"Source → Transform → Sink"的声明式流水线，核心优势体现在三个方面。

第一，声明式配置替代命令式编程。用户只需在 YAML 文件中声明数据源、路由规则和目标端，无需编写 Java 或 Scala 代码。这意味着数据工程师可以在不依赖开发团队的情况下独立完成同步任务的配置与部署。

第二，自动建表与字段映射。当源端 MySQL 中的表在目标端不存在时，Pipeline 会自动根据源表结构创建目标表，并完成字段类型映射。新增表无需手动干预，即可被自动纳入同步范围。

第三，Schema 变更的自动追踪与同步。当上游 MySQL 执行加减列、修改列类型等 DDL 操作时，Pipeline 能够自动捕获这些变更并将其传播到目标端。Flink CDC 3.6 进一步增强了 Schema Evolution 能力，支持 AlterTableCommentEvent 和 AlterColumnCommentEvent，并且默认在 include.schema.changes 选项中添加 create.table，让 Schema 变更的控制更加灵活。

核心架构：Source、Router、Sink

一个完整的 Pipeline 作业由三个核心组件构成，它们在 YAML 文件中以模块化的方式定义。

Source 模块负责从 MySQL 捕获增量数据。Flink CDC 3.6 的 MySQL Source 支持增量快照读取，具备无锁读取和断点续传能力。无论存量数据量多大，都可以通过横向提高并行度来加速全量快照阶段。同时，3.6 版本修复了多个关键问题：MySQL 大于 8.0 版本的兼容性问题、读取 binlog 时忽略新增表的问题、以及 GTID 恢复时可能的数据丢失问题。

Router 模块定义数据的路由规则。它决定源端的哪些表应该被同步到哪些目标端，支持正则表达式匹配和表名映射。3.6 版本引入了基于正则的路由匹配，并支持"匹配第一条规则"的确定性路由行为，避免了规则冲突带来的歧义。

Sink 模块负责将数据写入目标端。以 Doris Sink 为例，它基于 Stream Load 实现数据写入，通过两阶段提交保证端到端的 Exactly-Once 语义。写入延迟取决于 Checkpoint 间隔，但可以通过攒批机制在实时性和资源消耗之间取得平衡。

YAML 配置实战

下面是一个典型的 MySQL 整库同步到 Doris 的 YAML 配置示例：

source:
  type: mysql
  hostname: mysql-host
  port: 3306
  username: cdc_user
  password: xxxxxx
  databases: ["order_db", "user_db"]
  table: "order_.*|user_.*"

router:
  - source-table: "order_db\\.order_.*"
    sink-table: "doris_db.{source_table}"
  - source-table: "user_db\\.user_.*"
    sink-table: "doris_db.{source_table}"

sink:
  type: doris
  fenodes: "doris-fe:8030"
  username: root
  password: xxxxxx
  table.create.auto: true
  properties.format: json
  properties.read_json_by_line: true

这段配置的含义是：从 MySQL 的 order_db 和 user_db 两个库中，通过正则匹配 order_ 和 user_ 开头的所有表，将数据同步到 Doris 的 doris_db 中，目标表名与源表名保持一致。table.create.auto: true 开启了自动建表功能。

配置的关键细节需要注意：数据库和表的匹配规则使用点号分隔，正则中需要对点号进行转义；路由规则中的 {source_table} 占位符会被替换为实际的源表名；如果需要同步所有表，可以使用通配符 .*。

自动建表与 Schema 演化

自动建表的工作流程分为三个阶段。当 Pipeline 作业启动时，Source 端会先进行全量快照扫描，发现所有需要同步的表。对于每张表，Sink 端会检查目标端是否已存在对应的表结构。如果不存在，则根据源表的 DDL 信息自动创建目标表，并完成字段类型的映射转换。

Schema 演化则在运行时持续工作。当上游 MySQL 执行 ALTER TABLE 操作时，Binlog 中会记录相应的 DDL 事件。Source 端捕获这些事件后，将其封装为 SchemaChangeEvent 传递给 Sink 端。Sink 端解析变更类型（加列、减列、改列名、改列类型等），并自动在目标端执行相应的 DDL 操作。

以 Doris 为例，自 1.2 版本引入 Light Schema Change 机制后，增减列操作可以在毫秒级完成。这意味着当上游 MySQL 发生 Schema 变更时，数据同步任务无需暂停，整个过程对业务完全透明。

Flink CDC 3.6 对 Schema Evolution 进行了重要增强。除了支持标准的加减列操作外，还新增了对列注释和表注释变更的追踪能力。对于 Paimon Sink，3.6 版本新增了 VARIANT 类型支持，能够处理半结构化数据。对于 StarRocks Sink，则支持了重命名列和修改列类型的 DDL 操作。

生产环境注意事项

内存与并行度配置。 整库同步作业的并行度直接影响全量快照阶段的吞吐量。建议为每张表分配至少一个并行实例，对于大表可以适当增加。同时，需要注意 TaskManager 的内存配置，特别是当同步的表数量较多时，Source 端需要维护大量的 Split 状态。

Checkpoint 与 Exactly-Once。 Checkpoint 间隔决定了数据写入的延迟和资源消耗。间隔过短会导致 Checkpoint 频繁执行，增加 IO 压力；间隔过长则会增加故障恢复时的数据追赶时间。生产环境建议将 Checkpoint 间隔设置为 1-5 分钟，并启用增量 Checkpoint 以减少 Checkpoint 耗时。

Binlog 读取的稳定性。 在全量快照阶段，Source 端需要同时维护 Binlog 的读取位置。如果快照时间过长，可能导致 Binlog 被上游清理，触发全量重新扫描。建议合理配置 MySQL 的 Binlog 保留策略，至少保留 24 小时以上的 Binlog 数据。

新增表的处理。 当上游 MySQL 新增表时，Pipeline 需要在 Binlog 读取过程中感知到新表的创建事件。Flink CDC 3.6 修复了在读取 binlog 时可能忽略新增表的问题，但在实际部署中仍需确认 scan.newly-added-table.enabled 参数已正确配置。

失败恢复与断点续传。 Flink CDC 支持从 Checkpoint 恢复任务状态。当作业因异常中断时，可以从最近一次成功的 Checkpoint 恢复，避免全量重新同步。恢复后，Source 端会从上次记录的 Binlog 位置继续读取增量数据，确保数据的完整性和一致性。

监控与告警。 建议对 Pipeline 作业的关键指标进行监控，包括：Checkpoin 耗时、数据同步延迟（Source 端时间戳与 Sink 端时间戳的差值）、Sink 端的写入吞吐量、以及 Schema 变更事件的处理状态。当延迟超过阈值时，及时触发告警并排查原因。

从 DataStream 到 Pipeline 的迁移路径

对于已经使用 Flink CDC DataStream API 的存量作业，迁移到 Pipeline 架构是一个渐进的过程。建议先在测试环境验证 Pipeline 配置的正确性，然后采用灰度切换的方式逐步迁移。迁移过程中可以利用 Flink 的 Savepoint 机制，将 DataStream 作业的状态保存并在 Pipeline 作业中恢复，减少全量重新同步的成本。

需要特别注意的是，Pipeline 架构目前对自定义 Transform 逻辑的支持相对有限。如果存量作业中包含复杂的业务转换逻辑，可能需要评估是否适合迁移。Flink CDC 3.6 引入的 VARIANT 类型和 PARSE_JSON 函数为半结构化数据处理提供了更多可能性，但对于复杂的业务规则，DataStream API 仍然是更灵活的选择。

小结

Flink CDC 3.x 的 Pipeline 架构将 MySQL 整库同步从一项繁重的开发任务转变为一份声明式的配置文件。通过自动建表、Schema 变更追踪和断点续传等能力，它大幅降低了实时数据管道的构建和维护成本。在实际部署中，合理的并行度配置、Checkpoint 策略和 Binlog 管理是保证同步稳定性的关键。随着 Flink CDC 社区的持续迭代，Pipeline 架构正在成为企业实时数据集成的标准方案。