SeaTunnel CDC 连接器演进史：从 MySQL CDC 到多源全量增量一体化的版本全解析

SeaTunnel CDC 连接器演进史：从 MySQL CDC 到多源全量增量一体化的版本全解析

【免费下载链接】seatunnelSeaTunnel is a multimodal, high-performance, distributed, massive data integration tool.项目地址: https://gitcode.com/GitHub_Trending/se/seatunnel

导读

本文以 docs/zh/connectors/changelog/connector-cdc.md 中记录的 SeaTunnel CDC 连接器版本变更日志为主线，系统梳理 SeaTunnel（Zeta/Flink 引擎）在 2.3.0 → 2.3.12 期间 CDC（Change Data Capture，变更数据捕获）能力从无到有、从单库到多源、从全量快照到精确一次与 Schema 演进的完整技术演进路径。读完本文，你将掌握 SeaTunnel CDC 连接器的模块结构、快照分片与增量读取的底层机制、启动/停止模式与格式选项的配置方法，以及每个大版本引入的核心能力与典型修复，可直接用于排查问题、评估升级收益与编写实战配置。

一、CDC 连接器在 SeaTunnel 中的定位与模块结构

SeaTunnel 的 CDC 能力并不是单一连接器，而是一组以「增量快照（Incremental Snapshot）+ Debezium 嵌入式引擎」为核心的连接器族，按数据库拆分为多个独立 Maven 模块，全部位于仓库 seatunnel-connectors-v2/connector-cdc 下：

• connector-cdc-base：CDC 公共底座，包含分片（Split）、枚举器（Enumerator）、读取器（Reader）、偏移量（Offset）、Schema 变更解析等通用框架；
• connector-cdc-mysql：MySQL CDC（含 RDS MySQL），历史最悠久、能力最全；
• connector-cdc-oracle/connector-cdc-postgres/connector-cdc-sqlserver：传统关系型数据库 CDC；
• connector-cdc-mongodb：NoSQL 文档数据库 CDC；
• connector-cdc-tidb/connector-cdc-opengauss/connector-cdc-db2/connector-cdc-vitess：后加入的数据库适配。

在connector-cdc-base的 pom.xml 中维护了对 Debezium 内核的依赖，这也是 changelog 中 2.3.6 版本「[Improve][CDC] Bump the version of debezium to 1.9.8.Final (#6740)」的来源——所有数据库 CDC 的 binlog/redo log/WAL/oplog 解析都复用 Debezium 的能力。

从源码结构看，connector-cdc-base的核心骨架在 IncrementalSource.java，它统筹了三个关键子组件（位于source/enumerator/、source/reader/、source/split/目录）：

• SplitAssigner（分片分配器）：HybridSplitAssigner（快照+增量混合）、SnapshotOnlySplitAssigner（仅快照）、IncrementalSplitAssigner（仅增量），对应 changelog 中反复出现的「快照阶段/增量阶段」切换；
• IncrementalSourceReader（读取器）：通过 external/IncrementalSourceScanFetcher.java 与 external/IncrementalSourceStreamFetcher.java 分别执行全量快照扫描与增量流读取；
• Debezium 反序列化层：SeaTunnelRowDebeziumDeserializeSchema（默认行格式）与DebeziumJsonDeserializeSchema（兼容 Debezium JSON 格式），对应format选项。

在 2.3.0 时代，changelog 中的一批条目（#3363「CDC base classes」、#3419「CDC enumerator base classes」、#3455「mysql cdc reader」、#3481「MySQL CDC enumerator」、#3499「SeaTunnelRowDebeziumDeserializeSchema」）正是这批基础组件的落地记录，它们共同奠定了此后所有数据库 CDC 连接器的地基。

二、能力演进时间线：2.3.0 → 2.3.12

2.3.0：CDC 从 0 到 1

• 新增MySQL-CDCSource 连接器（#3707文档、#3667引入 E2E 容器、#3666修复实时任务下的读取错误），支持全量快照 + binlog 增量；
• 同步落地connector-cdc-sqlserver（#3686）；
• 引入 CDC 基础读取器、枚举器与SeaTunnelRowDebeziumDeserializeSchema（#3407、#3419、#3455、#3481、#3499、#3433）。

从该版本开始，CDC 连接器以INITIAL（先快照后增量）为默认启动方式，这一语义至今保留，见 StartupMode.java 中INITIAL的注释："Synchronize historical data at startup, and then synchronize incremental data."

2.3.1：多表、格式与运维能力爆发

这一版本集中交付了 CDC 走向生产级所需的大批能力：

• 多表读取与调度：#4067MySQL CDC 多表反序列化、#4147按 tableId 多行 shuffle、#4193修复多表解析、#4116多表 shuffle 批量处理；
• 分片表支持：#4207支持 sharding-tables（同构分片表合并读取）；
• 启动/停止模式重构：#4360、#4357将startup.mode/stop.mode改为SingleChoiceOption，统一了选项校验；
• 格式输出：#4351优化选项并补充compatible_debezium_json文档、#4339支持将 Debezium-JSON 格式导出到 Kafka；
• 恢复增强：#4254支持任务恢复时动态增删表、#4255支持按数据库列表读取；
• 可观测性：#4017引入 Connector-V2 指标（后续#6259修复了CDCRecordEmitDelay指标出现负值的问题）。

2.3.2：采样分片与多表扩展

• #4856实现「基于采样的分片策略（Sample-based Sharding）」并支持可配置采样率，解决超大表主键分布不均导致的分片倾斜问题，对应sample-sharding.threshold、inverse-sampling.rate等选项；
• #4377SQLServer CDC 支持多表读取；
• #4550catalog 支持连接复用（multiplexing connections），降低 JDBC 连接开销；
• #4670修复 MySQL TIME 类型为空、#4542修复TemporalConversions时间转换问题。

2.3.3：MongoDB、Schema 演进与精确一次

• #4923新增 MongoDB CDC Source（oplog 增量），并在 2.3.4#5644支持运行在 Flink 上；
• #5125引入 Schema Evolution 框架（DDL 事件传递），这是后续schema-changes.enabled选项与多表 sink DDL 同步的基石；
• #5057支持 CDC 精确一次语义并修复 BinlogOffset 比较 bug；#4921支持对 INITIAL 模式开关精确一次；#3837（2.3.1）保证快照切增量过程中的精确一次；
• #5147支持字符串类型作为分片字段、#5150支持无主键但有唯一键的表；
• #5105支持 MySQLtinyint(1)→ boolean 转换（后续演进为int_type_narrowing选项）。

2.3.4：Oracle/PostgreSQL 加盟与无主键表支持

• #5196支持 Oracle CDC、#5986支持 PostgreSQL CDC，并配套#6209无主键表读取、#6216自定义表主键、#6251无主键时修复无效 split key；
• #6106/#6098在 CDC base 层统一支持自定义主键与无主键表读取，#5384优先选择数值字段作为 split key；
• #6244默认关闭exactly_once以提升稳定性，#6017在关闭精确一次时禁用内存缓冲，#6245更新 PostgreSQL JDBC fetch size；
• #5756修复 JDBC 数据库标识符、#5668统一 SQLServer 类型转换模式、#5548增加 SQLServerdatetimeoffset数据类型。

2.3.5：性能与内存优化

• #6554优化增量阶段 split 状态的内存分配、#6281优化快照 split 读取的内存分配、#6571提升不含 schema 字段记录的读取性能；
• #6634支持监听 CDC source 中的消息延迟事件（对应MessageDelayedEventLimiter工具类）；
• #6419为 Job 增加事件监听器能力。

2.3.6：兼容性补全与性能修正

• #6929为 mysql-cdc 与 mysql-jdbc 支持 Schema Evolution；
• #6710支持 MySQL 5.5 老版本、#7046修复 GBK 编码 varchar 中文乱码；
• #6740将 Debezium 升级到 1.9.8.Final；
• #6526增量阶段关闭空闲子任务（reader/writer）组；
• #6785修复 Postgres/OpenGauss CDC 恢复时数据缺失；
• #6770为 MongoDB CDC 增加startup.mode = timestamp的条件校验。

2.3.7：稳定性修复

• #7381修复 MySQL binlog 读取中的ArrayIndexOutOfBoundsException；#7248优化 Oracle JDBC 与 Oracle CDC 的行数统计。

2.3.8：新数据库与 DDL 去重

• #7433支持 opengauss-cdc、#7477支持 TiDB CDC source；
• #7706SQLServer 支持用户自定义类型，#7715优化 SQLServer 包结构；
• #7634修复配置multi_table_sink_replica时 DDL 重复执行问题。

2.3.9：通配符扫描与 schema-changes.enabled

• #8323MySQL CDC 支持database-pattern/table-pattern正则通配扫描读取（#5365避免在无关数据库下列举表的优化也在此前合并）；
• #8029MongoDB CDC 支持多表读取，#7935设置SeatunnelRow的 tableId；
• #8285/#8252新增schema-changes.enabled选项（2.3.3 的 Schema Evolution 框架正式暴露为配置）；
• #7463Zeta 引擎支持 CDC 任务 DDL 恢复，#7840增加snapshotSplitColumn自定义快照拆分列；
• #7918修复快照 split 读取时偶发数据库连接泄漏、#7950修复值为 null 时使用默认值的问题；
• #7899新增 metadata transform，#7908支持 Oracle 连接器 Schema Evolution。

2.3.10：增量读取健壮性

• #8569过滤 heartbeat 事件、#8911快照阶段过滤 DDL、#8906抽取重复代码；
• #8560PostgreSQL CDC 支持数组类型、#8912Oracle CDC 支持ReadOnlyLogWriterFlushStrategy；
• #8528修复从 checkpoint 恢复时基于 GTID 的启动逻辑、#8587修复 binlog 被清理导致的恢复任务失败；
• #8754MongoDB CDC 在 resume token 过期时回退到 timestamp 启动模式。

2.3.11：类型与 DDL 事件修正

• #9314修复 Oracle rename DDL 事件缺少列类型、#9305支持将 Oracle BLOB 按字符串而非字节数组读取；
• #9052修复 postgres-cdc 与debezium_json格式组合时无法解析无小数位数数字的问题。

2.3.12：最新能力快照

• #9735MySQL CDC 支持按时间启动（start by time）；
• #9720支持 MySQL 8.4+；
• #9650为每个连接器增加独立插件目录支持；
• #9671优化 enumerator API 语义并减少连接器层锁调用、#9586将元数据 schema 纳入 catalog table；
• #9546优化 CDC JAR 文件体积；
• #9454修复 MongoDBisExactlyOnce默认 true 导致的问题；
• #9434修正batch-size-per-scan选项键的拼写错误；
• #9412修复 Oracle CDC 在启用 LOB 时不更新事务提交的问题、#9373支持 MySQLtinyint(1)读取为 byte(tinyint)。

三、启动模式与停止模式：配置语义与源码印证

启动/停止模式是 CDC 配置中最核心的部分，changelog 中 2.3.1#4360「Improve startup.mode/stop.mode options」、#4357「Update CDC StartupMode and StopMode option to SingleChoiceOption」以及 2.3.12#9735「MySQL cdc support start by time」都是围绕这一组配置的迭代。

从 StartupMode.java 可以看到完整枚举：EARLIEST、LATEST、INITIAL、SNAPSHOT_ONLY、COMMITTED_OFFSET、TIMESTAMP、SPECIFIC。而 MySQL 连接器在 MySqlIncrementalSourceOptions.java 中开放了其中五种：

specific模式还支持可选增强参数：startup.specific-offset.gtid-set（GTID 集合，需与 file/pos 联用，对应 2.3.10#8528的 GTID 恢复修复）、startup.specific-offset.skip-events与startup.specific-offset.skip-rows（在启动偏移后跳过指定数量的 binlog 事件/行）。在 MySqlIncrementalSource.java 的createStartupConfig方法中可以看到其实现：SPECIFIC 模式走 map 形式的 offset 路径以支持 GTID 与 skip 元数据，其余模式则校验「不得混填 specific offset 参数」后构造常规StartupConfig。

停止模式在 MySqlIncrementalSourceOptions.java 中支持never（默认，持续运行）、latest、specific（配合stop.specific-offset.file/stop.specific-offset.pos实现有界读取）。有界读取的作业在消费完启动与停止偏移之间的数据后以FINISHED状态自行终止——需要说明的是，这一终止行为目前仅 Zeta 引擎支持，Flink/Spark 引擎暂不支持有界增量分片终止（见 MySQL-CDC.md 中「有界读取」一节）。

一个典型的「从指定 binlog 位置启动并在指定位置停止」的有界读取配置如下：

source { MySQL-CDC { server-id = 5654 username = "st_user_source" password = "mysqlpw" table-names = ["mysql_cdc.mysql_cdc_e2e_source_table"] url = "jdbc:mysql://mysql_cdc_e2e:3306/mysql_cdc" startup.mode = "specific" startup.specific-offset.file = "mysql-bin.000001" startup.specific-offset.pos = 154 stop.mode = "specific" stop.specific-offset.file = "mysql-bin.000010" stop.specific-offset.pos = 4096 } }

stop.mode = "specific"同样可以与startup.mode = "timestamp"组合，同时按时间与 binlog 位置限定读取范围。

四、全量快照与增量切换的底层机制

changelog 中大量条目围绕「快照分片」与「快照→增量切换」展开，这是理解 CDC 性能与正确性的关键。

4.1 快照分片（Snapshot Split）

全量阶段，CDC 连接器并不会整表一把梭，而是把表按主键（或唯一键）范围切成多个 split 并发读取。相关配置（默认值来自 SourceOptions.java 与 MySQL-CDC.md）：

分片均匀性控制则来自 changelog 2.3.2#4856引入的采样分片策略，配套参数：

• chunk-key.even-distribution.factor.upper-bound（默认 100）与chunk-key.even-distribution.factor.lower-bound（默认 0.05）：通过(MAX(id) - MIN(id) + 1) / row count判断表数据分布是否均匀；
• sample-sharding.threshold（默认 1000）：当分布因子超出上下界且预估分片数超过该阈值时，切换到采样分片策略；
• inverse-sampling.rate（默认 1000）：采样率的倒数，即应用 1/1000 的采样率；
• split.allow-sampling（默认 true）：置 false 时回退到非均匀分片（迭代查询）方式。

此外，2.3.9#7840引入的snapshotSplitColumn（通过table-names-config按表配置）允许为每张表显式指定快照拆分列，且该列应是主键或唯一键。

4.2 快照→增量切换的精确一次保证

changelog 2.3.1#3837「Guaranteed to be exactly-once in the process of switching from SnapshotTask to IncrementalTask」保证了快照与增量衔接处的数据不重不漏：快照开始时记录 binlog 水位（watermark），快照完成后从该水位无缝切入增量流。对应实现位于 split/wartermark/WatermarkEvent.java（SnapshotSplitWatermark事件）与CompletedSnapshotPhaseEvent等事件类中。

4.3 无主键表的读取策略

默认情况下 CDC 要求表有主键；无主键表的支持是 2.3.3#5150、2.3.4#6098迭代的成果，当前策略分为两条路径（见 MySQL-CDC.md「读取没有主键的表」）：

• 仅追加（append-only）场景：源表不产生 UPDATE/DELETE，保持exactly_once = false且不声明主键，连接器退回尽力而为的行标识；
• 存在唯一非主键列：通过table-names-config.primaryKeys显式声明该列为逻辑主键，并设置exactly_once = true，让快照与 binlog 阶段使用同一稳定行标识：

source { MySQL-CDC { server-id = 5652 username = "st_user_source" password = "mysqlpw" table-names = ["mysql_cdc.mysql_cdc_e2e_source_table_no_primary_key"] url = "jdbc:mysql://mysql_cdc_e2e:3306/mysql_cdc" table-names-config = [ { table = "mysql_cdc.mysql_cdc_e2e_source_table_no_primary_key" primaryKeys = ["id"] } ] exactly_once = true } }

需要强调的是：只有当被声明的列在源数据中确实唯一时，UPDATE/DELETE 才能被正确路由；若存在重复值，行为将不再可靠。

五、格式、Schema 演进与 DDL 事件

5.1 输出格式：DEFAULT 与 compatible_debezium_json

format选项（默认DEFAULT，即 SeaTunnel Row 行格式）支持切换为compatible_debezium_json，这是 2.3.1#4339/#4351引入的能力：将 CDC 记录序列化为与 Debezium 生态兼容的 JSON，直接写入 Kafka 等 MQ，实现与既有 Debezium 下游生态的无缝对接。典型配置（完整示例见 cdc-compatible-debezium-json.md）：

source { MySQL-CDC { plugin_output = "table1" url = "jdbc:mysql://localhost:3306/test" "startup.mode" = INITIAL table-names = ["database1.t1", "database1.t2", "database2.t1"] format = compatible_debezium_json debezium = { key.converter.schemas.enable = false value.converter.schemas.enable = false database.server.name = "mysql_cdc_1" } } } sink { Kafka { plugin_input = "table1" bootstrap.servers = "localhost:9092" topic = "${topic}" format = compatible_debezium_json } }

其中database.server.name用于生成 topic 前缀（{database.server.name}.{database}.{table}），2.3.12#9586又将元数据 schema（如 tableId、操作类型、binlog 位置等）纳入 catalog table，进一步丰富了输出元数据。

5.2 Schema 演进与 schema-changes.enabled

Schema 演进能力沿三条主线演进：2.3.3#5125引入 DDL 框架 → 2.3.6#6929为 mysql-cdc 落地 → 2.3.9#8285暴露为schema-changes.enabled选项。启用后连接器可将源端 DDL 事件发送到下游（如 JDBC sink 自动执行 DDL），支持add column、drop column、rename column、modify column四类变更。

2.3.9 之后又增加了schema-changes.include/schema-changes.exclude两个过滤选项，采用 SeaTunnel 统一规范名称：add.column、drop.column、modify.column、change.column，以及作为上述四种列级变更分组别名的update.columns。优先级规则是确定性的：先应用 include（未列出者无资格），再应用 exclude，两者冲突时 exclude 优先。底层实现在 SchemaChangeEventFilter.java（仓库中同时提供 SchemaChangeEventFilterTest.java 覆盖该优先级逻辑）。

典型配置：

source { MySQL-CDC { server-id = 5652-5657 username = "st_user_source" password = "mysqlpw" table-names = ["shop.products"] url = "jdbc:mysql://mysql_cdc_e2e:3306/shop" schema-changes.enabled = true schema-changes.include = ["add.column", "drop.column"] schema-changes.exclude = ["change.column"] } }

使用提示：若在 include 中保留drop.column而源端被删除的列在 sink 端是 NOT NULL，写入 NULL 会被 sink 拒绝导致失败，因此对这类列需要谨慎处理过滤策略。

DDL 事件的恢复能力是另一个关键点：2.3.8#7634修复了配置multi_table_sink_replica时 DDL 重复执行的问题；2.3.9#7463让 Zeta 引擎支持 CDC 任务 DDL 恢复；2.3.4#6118修复了任务恢复后新增列无法解析的问题；2.3.11#9314修复了 Oracle rename DDL 事件缺少列类型的问题——这些修复共同保障了「Schema 演进 + 任务恢复」组合场景下的正确性。

六、多表读取、自定义主键与生产级配置

6.1 多表与通配符读取

MySQL CDC 自 2.3.1#4067起支持多表反序列化，随后演进出两种表选择方式（二者只能选其一）：

• table-names：精确列表，如["testdb.table1", "testdb.table2"]；
• table-pattern/database-pattern：正则通配（2.3.9#8323），例如：

source { MySQL-CDC { server-id = 5652 username = "st_user_source" password = "mysqlpw" database-pattern = "source.*" table-pattern = "source.*\\..*" url = "jdbc:mysql://mysql_cdc_e2e:3306" } }

多表读取后写入 JDBC sink 时，可用占位符保留原始表名（table = "${table_name}"、primary_keys = ["${primary_key}"]），配合plugin_output/plugin_input完成 source 与 sink 的通道绑定。

6.2 自定义主键与按表独立配置

table-names-config支持按表配置自定义主键与快照拆分列：

source { MySQL-CDC { url = "jdbc:mysql://localhost:3306/testdb" username = "root" password = "root@123" table-names = ["testdb.table1", "testdb.table2"] table-names-config = [ { table = "testdb.table2" primaryKeys = ["id"] } ] } }

6.3 完整的生产级任务示例

综合上述能力，一个多表 CDC 同步到 JDBC 的完整任务（源自 MySQL-CDC.md）：

env { parallelism = 1 job.mode = "STREAMING" checkpoint.interval = 10000 } source { MySQL-CDC { url = "jdbc:mysql://localhost:3306/testdb" username = "root" password = "root@123" table-names = ["testdb.table1", "testdb.table2"] startup.mode = "initial" } } sink { Console { } }

如需 Schema 演进 + 精确一次写入，则组合schema-changes.enabled = true与 JDBC 2PC sink（is_exactly_once = true、xa_data_source_class_name）。更完整的生产级端到端实践可参考 CDC 生产实战手册 与 Schema Evolution 文档。

6.4 连接与鉴权前置条件

• MySQL 用户权限：GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'user'@'%';
• binlog 开关（my.cnf/my.ini）：log_bin = mysql-bin、binlog_format = ROW、binlog_row_image = FULL（MySQL 5.6+ 必须 FULL；GTID 模式为可选但推荐）。
• server-id 唯一性：每个 CDC 任务必须使用唯一server-id或互不重叠的范围（如5400-5408），重复会导致 MySQL 主动断开其中一个客户端连接。未配置时 SeaTunnel 会随机生成，但生产环境建议显式配置；2.3.4#5550曾优化默认 server-id 的取值区间以减少冲突。
• 低流量表的心跳：通过debezium.heartbeat.interval.ms与debezium.heartbeat.action.query配置心跳（对应 2.3.10#8569对 heartbeat 事件的过滤处理），让 binlog 位置持续向前滚动。

6.5 类型映射要点

MySQL CDC 的默认类型映射（详见 MySQL-CDC.md 数据类型映射表）：

• BIT(1)/TINYINT(1)→ BOOLEAN（由int_type_narrowing控制，默认 true；置 false 时映射为 TINYINT，2.3.3#5105与 2.3.12#9373均与该项相关）；
• TINYINT→ TINYINT，TINYINT UNSIGNED/SMALLINT→ SMALLINT；
• SMALLINT UNSIGNED/MEDIUMINT/INT/INTEGER/YEAR→ INT；
• INT UNSIGNED/BIGINT→ BIGINT；BIGINT UNSIGNED→ DECIMAL(20,0)；
• DECIMAL(p,s)→ DECIMAL(p,s)，FLOAT→ FLOAT，DOUBLE/REAL→ DOUBLE；
• 字符/文本/ENUM/JSON → STRING；DATE→ DATE，TIME(s)→ TIME(s)，DATETIME/TIMESTAMP(s)→ TIMESTAMP(s)；
• BINARY/VARBINARY/BIT(p)/ 各类 BLOB /GEOMETRY→ BYTES。

七、测试验证与源码印证路径

changelog 中的大量「Fix」「Hotfix」条目都有对应的单元测试或 E2E 测试支撑，可在仓库中直接验证：

• 分片分配器：HybridSplitAssignerTest.java、SnapshotSplitAssignerTest.java、IncrementalSplitAssignerTest.java，覆盖快照/增量阶段的 split 分配状态机；
• 反序列化：SeaTunnelRowDebeziumDeserializationConvertersTest.java、DebeziumJsonDeserializeSchemaTest.java、SeaTunnelRowDebeziumDeserializeSchemaRestoreTest.java（恢复场景）；
• 启动配置：MySqlIncrementalSourceStartupConfigTest.java 与 MySqlIncrementalSourceFactoryTest.java；
• 分片器：AbstractJdbcSourceChunkSplitterTest.java；
• 工具类：MessageDelayedEventLimiterTest.java、SourceRecordUtilsTest.java。

E2E 层面，connector-cdc-mysql-e2e、connector-cdc-oracle-e2e 等模块以 Docker 容器方式启动真实数据库验证全量+增量链路，2.3.0#3667、2.3.4#8292等 changelog 条目正是这些测试基建的落地记录。

八、升级建议与版本选型指引

结合 changelog 的能力时间线，可按需求场景给出选型参考：

• 仅需 MySQL 单表全量+增量：2.3.0 已具备；若需精确一次与更好的稳定性，建议 2.3.4+（exactly_once默认关闭、内存缓冲策略优化）；
• 需要多表、通配符与分片表：2.3.1 提供多表与 sharding-tables，2.3.9 提供database-pattern/table-pattern正则扫描；
• 需要 Oracle / PostgreSQL / SQLServer / TiDB / OpenGauss / MongoDB：分别从 2.3.4（Oracle、PostgreSQL）、2.3.0（SQLServer）、2.3.8（TiDB、OpenGauss）、2.3.3（MongoDB）开始支持，后续版本持续修复类型映射与恢复问题；
• 需要 Schema 演进（DDL 下发）：2.3.9+（schema-changes.enabled），2.3.9#7463补齐 Zeta 的 DDL 恢复；
• 需要 Debezium-JSON 生态对接（Kafka）：2.3.1+，2.3.12#9586进一步丰富元数据；
• 大表快照性能敏感：2.3.2 采样分片 + 2.3.5 内存优化，配合snapshot.split.size、sample-sharding.threshold等参数调优；
• 需要 MySQL 8.4+ 或按时间启动：需 2.3.12+（#9720、#9735）。

上述版本号均来自 changelog 中「Version」列所标注的 SeaTunnel 发行版本，实际使用时请以所选版本对应分支的 docs/zh/connectors/source 文档为准，并留意各数据库版本兼容矩阵（如 MySQL 官方支持 5.5/5.6/5.7/8.0.x，8.4+ 自 2.3.12 起支持）。

九、结语

从 2.3.0 的 MySQL 单连接器，到 2.3.12 覆盖 MySQL/Oracle/PostgreSQL/SQLServer/MongoDB/TiDB/OpenGauss 等多数据源、支持采样分片、精确一次、Schema 演进与 Debezium-JSON 生态对接的完整 CDC 家族，SeaTunnel CDC 连接器的演进清晰地遵循「先打地基（base 框架）→ 扩展数据源 → 补齐正确性 → 开放高级能力」的节奏。理解这份 changelog 背后的能力脉络，既能帮助你在配置中精准选用startup.mode、format、schema-changes.enabled等选项，也能在遇到快照慢、恢复丢数据、DDL 冲突等问题时快速定位到对应版本与修复逻辑。建议后续结合 MySQL-CDC 连接器文档、CDC 生产实战手册 与各 CDC 连接器的源码与测试用例，做进一步的实战验证。

【免费下载链接】seatunnelSeaTunnel is a multimodal, high-performance, distributed, massive data integration tool.项目地址: https://gitcode.com/GitHub_Trending/se/seatunnel