You need to enable JavaScript to run this app.
文档中心
大数据研发治理套件

大数据研发治理套件

请输入
  • 文档首页
    • 大数据研发治理套件常见问题数据集成实时同步任务Schema变更常见问题与处置指南
复制全文
下载 pdf
我的收藏
数据集成
实时同步任务Schema变更常见问题与处置指南
复制全文
下载 pdf
我的收藏
实时同步任务Schema变更常见问题与处置指南

1 常见问题速查

类别

判断依据

典型表现

2.1 结构变更被策略忽略或拒绝

收到变更，但生效策略不符合同步需求。

缺字段，或后续数据出现类型转换异常。

2.2 Source Schema 与 Binlog 不一致

消费位点对应的列数、顺序或类型与解码 Schema 不匹配。

解码或转换报错，也可能静默写入错值；Online DDL 切换异常是触发场景之一。

2.3 DDL 语法解析失败

Source 解析原始 DDL 时抛出异常。

ParsingException，DDL 无法解析。

同一种类型转换报错可能发生在不同环节。应结合生效配置、原始 DDL、异常堆栈及数据结果判断，不能仅凭异常名称归类。

2 典型问题

2.1 结构变更被策略忽略或拒绝

任务收到结构变更，但新增列、删除列、类型变更等策略不符合同步需求，目标继续保留旧结构。

案例一：删除列被忽略，同名列重加后类型冲突

源端删除 BIGINT 列后，因删除列策略为 IGNORE，目标保留旧列。随后同名重加为 VARCHAR，后续字符串无法按旧 BIGINT 处理。

  • 完整报错日志：

    2026-09-28 14:27:01.656 [SchemaPipeline_db_yu -> PackingPipeline (1/1)- execution # 0] WARN  org.apache.flink.runtime.taskmanager.Task - SchemaPipeline_db_yu -> PackingPipeline (1/1)- execution # 0 (503b818d7115b8816027754e7ef48b6a) switched from RUNNING to FAILED java.lang.IllegalStateException: Unable to fill null for empty columns
        at com.bytedance.bitsail.connector.cdc.runtime.operators.schema.SchemaOperator.normalizeSchemaChangeEvents(SchemaOperator.java:422)
        at com.bytedance.bitsail.connector.cdc.runtime.operators.schema.SchemaOperator.lambda$processDataChangeEvents$0(SchemaOperator.java:328)
        at java.util.Collections$SingletonList.forEach(Collections.java:4824)
        at com.bytedance.bitsail.connector.cdc.runtime.operators.schema.SchemaOperator.processDataChangeEvents(SchemaOperator.java:324)
        at com.bytedance.bitsail.connector.cdc.runtime.operators.schema.SchemaOperator.processElement(SchemaOperator.java:240)
        at org.apache.flink.streaming.runtime.io.RecordProcessorUtils.processElement(RecordProcessorUtils.java:36)
        at org.apache.flink.streaming.runtime.tasks.OneInputStreamTask$StreamTaskNetworkOutput.emitRecordInternal(OneInputStreamTask.java:296)
        at org.apache.flink.streaming.runtime.tasks.OneInputStreamTask$StreamTaskNetworkOutput.emitRecord(OneInputStreamTask.java:283)
        at org.apache.flink.streaming.runtime.io.StreamTaskNetworkInput.processElement(StreamTaskNetworkInput.java:256)
        at org.apache.flink.streaming.runtime.io.StreamTaskNetworkInput.emitNext(StreamTaskNetworkInput.java:224)
        at org.apache.flink.streaming.runtime.io.StreamOneInputProcessor.processInput(StreamOneInputProcessor.java:67)
        at org.apache.flink.streaming.runtime.tasks.StreamTask.processInput(StreamTask.java:498)
        at org.apache.flink.streaming.runtime.tasks.mailbox.MailboxProcessor.runMailboxLoop(MailboxProcessor.java:191)
        at org.apache.flink.streaming.runtime.tasks.StreamTask.runMailboxLoop(StreamTask.java:997)
        at org.apache.flink.streaming.runtime.tasks.StreamTask.executeInvoke(StreamTask.java:942)
        at org.apache.flink.streaming.runtime.tasks.StreamTask.runWithCleanUpOnFail(StreamTask.java:954)
        at org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:926)
        at org.apache.flink.runtime.taskmanager.Task.doRun(Task.java:1061)
        at org.apache.flink.runtime.taskmanager.Task.run(Task.java:831)
        at java.lang.Thread.run(Thread.java:750)
Caused by: java.lang.IllegalArgumentException: Cannot fit type "class com.bytedance.bitsail.connector.cdc.common.data.binary.BinaryStringData" into a BIGINT column. Currently only TINYINT / SMALLINT / INT can be accepted by a BIGINT column
        at com.bytedance.bitsail.connector.cdc.runtime.operators.schema.SchemaOperator$TypeCoercionFieldGetter.getFieldOrNull(SchemaOperator.java:778)
        at com.bytedance.bitsail.connector.cdc.runtime.operators.schema.SchemaOperator.lambda$regenerateRecordData$2(SchemaOperator.java:489)
        at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
        at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1384)
        at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
        at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
        at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:546)
        at java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
        at java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
        at java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:444)
        at com.bytedance.bitsail.connector.cdc.runtime.operators.schema.SchemaOperator.regenerateRecordData(SchemaOperator.java:490)
        at com.bytedance.bitsail.connector.cdc.runtime.operators.schema.SchemaOperator.normalizeSchemaChangeEvents(SchemaOperator.java:359)
        ... 19 more
.

  • 处置：​仅修改策略并从 DROP 后的 Checkpoint 恢复，不会重新执行已跳过的 DROP。需核对任务和目标结构，再选择对齐结构或历史回放。重放 DROP 会清除目标旧列值，历史数据需另行核对。

案例二：忽略类型变更，安全范围内的值也转换失败

源字段从 INT 变更为 BIGINT UNSIGNED，类型变更策略为 IGNORE。即使值为 101、未超出 INT 范围，也可能因运行时类型由 Integer 变为 Long 而转换失败，不能仅解释为数值溢出。

  • 完整报错日志：

    2026-09-28 14:28:07.148 [SchemaPipeline_db_yu -> PackingPipeline (1/1)- execution # 0] WARN  org.apache.flink.runtime.taskmanager.Task - SchemaPipeline_db_yu -> PackingPipeline (1/1)- execution # 0 (9fcb3090afac1eda1ab30256488fac8f) switched from RUNNING to FAILED java.lang.IllegalStateException: Unable to fill null for empty columns
        at com.bytedance.bitsail.connector.cdc.runtime.operators.schema.SchemaOperator.normalizeSchemaChangeEvents(SchemaOperator.java:422)
        at com.bytedance.bitsail.connector.cdc.runtime.operators.schema.SchemaOperator.lambda$processDataChangeEvents$0(SchemaOperator.java:328)
        at java.util.Collections$SingletonList.forEach(Collections.java:4824)
        at com.bytedance.bitsail.connector.cdc.runtime.operators.schema.SchemaOperator.processDataChangeEvents(SchemaOperator.java:324)
        at com.bytedance.bitsail.connector.cdc.runtime.operators.schema.SchemaOperator.processElement(SchemaOperator.java:240)
        at org.apache.flink.streaming.runtime.io.RecordProcessorUtils.processElement(RecordProcessorUtils.java:36)
        at org.apache.flink.streaming.runtime.tasks.OneInputStreamTask$StreamTaskNetworkOutput.emitRecordInternal(OneInputStreamTask.java:296)
        at org.apache.flink.streaming.runtime.tasks.OneInputStreamTask$StreamTaskNetworkOutput.emitRecord(OneInputStreamTask.java:283)
        at org.apache.flink.streaming.runtime.io.StreamTaskNetworkInput.processElement(StreamTaskNetworkInput.java:256)
        at org.apache.flink.streaming.runtime.io.StreamTaskNetworkInput.emitNext(StreamTaskNetworkInput.java:224)
        at org.apache.flink.streaming.runtime.io.StreamOneInputProcessor.processInput(StreamOneInputProcessor.java:67)
        at org.apache.flink.streaming.runtime.tasks.StreamTask.processInput(StreamTask.java:498)
        at org.apache.flink.streaming.runtime.tasks.mailbox.MailboxProcessor.runMailboxLoop(MailboxProcessor.java:191)
        at org.apache.flink.streaming.runtime.tasks.StreamTask.runMailboxLoop(StreamTask.java:997)
        at org.apache.flink.streaming.runtime.tasks.StreamTask.executeInvoke(StreamTask.java:942)
        at org.apache.flink.streaming.runtime.tasks.StreamTask.runWithCleanUpOnFail(StreamTask.java:954)
        at org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:926)
        at org.apache.flink.runtime.taskmanager.Task.doRun(Task.java:1061)
        at org.apache.flink.runtime.taskmanager.Task.run(Task.java:831)
        at java.lang.Thread.run(Thread.java:750)
Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.Integer
        at com.bytedance.bitsail.connector.cdc.runtime.serializer.data.writer.BinaryWriter.write(BinaryWriter.java:109)
        at com.bytedance.bitsail.connector.cdc.runtime.typeutils.BinaryRecordDataGenerator.generate(BinaryRecordDataGenerator.java:91)
        at com.bytedance.bitsail.connector.cdc.runtime.operators.schema.SchemaOperator.regenerateRecordData(SchemaOperator.java:487)
        at com.bytedance.bitsail.connector.cdc.runtime.operators.schema.SchemaOperator.normalizeSchemaChangeEvents(SchemaOperator.java:359)
        ... 19 more
.

  • 处置：​核对运行版本的类型转换能力和目标承载范围，根据实际需求执行目标类型变更或使用已验证的兼容转换。

2.2 Source Schema 与 Binlog 不一致：报错或静默错列

Source 解码某个位点的 Binlog 时，使用的 Schema 必须与该事件对应的表结构一致，包括列数、列顺序和类型。Online DDL 切换未被正确处理，是造成这种不一致的一种场景；历史位点与启动 Schema 不配套，也会造成同类问题。
可以按“结构变更或恢复操作 → Schema 与事件不一致 → 消费受影响的 DML → 报错或写入错值”理解。造成不一致的操作与问题暴露可以发生在不同时间；静默错列本身已经是数据错误，不必等到任务报错才算触发。

哪些场景会造成不一致

场景

不一致如何产生

后续可能表现

从 ADD 前的历史位点启动，却使用 ADD 后的当前 Schema。

历史 Row 列少，解码 Schema 需要的列多。

访问不存在的列位置时报 Data row is smaller than a column index；下方案例一已复现。

Online DDL 在中间加列，切换后仍使用旧 Schema。

新事件的列布局已改变，任务仍按旧布局处理。

可能静默错列，也可能解码或转换失败；下方案例二已复现静默错值。

删除列的变更未进入 Source Schema，继续读取删列后的数据。

旧 Schema 保留已删除列，后续列位置或列数发生变化。

可能越界报错或错列，取决于实际访问的列位置与解码路径。

列数不变，但列顺序或类型变化未进入 Source Schema。

列数检查可能通过，字段含义或类型已经变化。

错位后的值若能继续处理，可能静默写错；无法处理时可能转换失败。

手工指定的历史 Schema 与启动位点不配套。

列数、顺序或类型与该位点事件不同。

同样可能报错或静默错列，不能只核对列数。

源端引擎生成的隐藏主键未进入 Source Schema。

Binlog 包含隐藏首列，但初始化或恢复的 Schema 只有业务列，物理位置不一致。

可能转换报错或静默错列；下方案例三为历史排查证据，未完成完整 E2E 验收。

案例一：历史两列数据使用当前三列 Schema，直接报错

源表原来是 (id, payload)，新增 vip_level 后变为 (id, payload, vip_level)。任务从新增列之前的位点启动，却使用当前三列结构解码历史两列数据；访问第三列时出现以下异常。
完整报错日志：

2026-09-28 14:27:43.836 [blc-mysqlc98cae55f38d.rds.ivolces.com:3306] ERROR io.debezium.pipeline.ErrorHandler - Producer failure
io.debezium.DebeziumException: Error processing binlog event
        at io.debezium.connector.mysql.MySqlStreamingChangeEventSource.handleEvent(MySqlStreamingChangeEventSource.java:451) ~[connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        at com.bytedance.bitsail.connector.cdc.mysql.source.reader.MySqlIncrementBinlogFetchTask$EventFilterMySqlStreamingChangeEventSource.handleEvent(MySqlIncrementBinlogFetchTask.java:129) ~[connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        at io.debezium.connector.mysql.MySqlStreamingChangeEventSource.lambda$execute$26(MySqlStreamingChangeEventSource.java:1154) ~[connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        at com.github.shyiko.mysql.binlog.BinaryLogClient.notifyEventListeners(BinaryLogClient.java:1298) [connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        at com.github.shyiko.mysql.binlog.BinaryLogClient.listenForEventPackets(BinaryLogClient.java:1118) [connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        at com.github.shyiko.mysql.binlog.BinaryLogClient.connect(BinaryLogClient.java:646) [connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        at com.github.shyiko.mysql.binlog.BinaryLogClient$7.run(BinaryLogClient.java:947) [connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        at java.lang.Thread.run(Thread.java:750) [?:1.8.0_411]
Caused by: com.bitsail.shaded.debezium.org.apache.kafka.connect.errors.ConnectException: Error while processing event at offset {transaction_id=null, ts_sec=1790576835, file=binlog.000197, pos=1115255, gtids=3309b3a5-b4c0-11f1-a652-52540bdb2dfc:690051-690051, row=1, server_id=3886972005, event=2}
        at io.debezium.pipeline.EventDispatcher.dispatchDataChangeEvent(EventDispatcher.java:246) ~[connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        at io.debezium.connector.mysql.MySqlStreamingChangeEventSource.lambda$handleInsert$4(MySqlStreamingChangeEventSource.java:882) ~[connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        at io.debezium.connector.mysql.MySqlStreamingChangeEventSource.handleChange(MySqlStreamingChangeEventSource.java:988) ~[connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        at io.debezium.connector.mysql.MySqlStreamingChangeEventSource.handleInsert(MySqlStreamingChangeEventSource.java:873) ~[connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        at io.debezium.connector.mysql.MySqlStreamingChangeEventSource.lambda$execute$16(MySqlStreamingChangeEventSource.java:1111) ~[connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        at io.debezium.connector.mysql.MySqlStreamingChangeEventSource.handleEvent(MySqlStreamingChangeEventSource.java:430) ~[connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        ... 7 more
Caused by: com.bitsail.shaded.debezium.org.apache.kafka.connect.errors.ConnectException: Data row is smaller than a column index, internal schema representation is probably out of sync with real database schema
        at io.debezium.relational.TableSchemaBuilder.validateIncomingRowToInternalMetadata(TableSchemaBuilder.java:254) ~[connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        at io.debezium.relational.TableSchemaBuilder.lambda$createValueGenerator$5(TableSchemaBuilder.java:283) ~[connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        at io.debezium.relational.TableSchema.valueFromColumnData(TableSchema.java:141) ~[connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        at io.debezium.relational.RelationalChangeRecordEmitter.emitCreateRecord(RelationalChangeRecordEmitter.java:71) ~[connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        at io.debezium.relational.RelationalChangeRecordEmitter.emitChangeRecords(RelationalChangeRecordEmitter.java:47) ~[connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        at io.debezium.pipeline.EventDispatcher.dispatchDataChangeEvent(EventDispatcher.java:209) ~[connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        at io.debezium.connector.mysql.MySqlStreamingChangeEventSource.lambda$handleInsert$4(MySqlStreamingChangeEventSource.java:882) ~[connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        at io.debezium.connector.mysql.MySqlStreamingChangeEventSource.handleChange(MySqlStreamingChangeEventSource.java:988) ~[connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        at io.debezium.connector.mysql.MySqlStreamingChangeEventSource.handleInsert(MySqlStreamingChangeEventSource.java:873) ~[connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        at io.debezium.connector.mysql.MySqlStreamingChangeEventSource.lambda$execute$16(MySqlStreamingChangeEventSource.java:1111) ~[connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        at io.debezium.connector.mysql.MySqlStreamingChangeEventSource.handleEvent(MySqlStreamingChangeEventSource.java:430) ~[connector-cdc-mysql-v3-0.2.0-SNAPSHOT.jar:?]
        ... 7 more

案例二：Online DDL 中间加列，切换后静默错列

源表原来是 (id, payload, amount)。影子表在 id 后新增 vip_level，切换后的顺序变为 (id, vip_level, payload, amount)。本次关闭 Online DDL 协议并模拟影子表切换后，目标仍保留旧的三列结构。
切换后写入 (2, 'GOLD', 'after_cutover', 200)，实际结果如下：

字段

源端值

目标实际值

id

2

2

vip_level

GOLD

无此列

payload

after_cutover

GOLD

amount

200

171798691853

该记录成功落库，没有对应的业务异常，但数据已经错误。payload 接收了新插入位置的值；amount 也出现异常值，不能把影响只理解为字段名称对应错了。

案例三：引擎隐藏主键未进入 Source Schema

历史排查表 dts_test_do_not_delete.impalatest156 有 7 个业务字段，Binlog 中还有引擎生成的隐藏首列 byte_rds_ai_uk_row_id，共 8 个物理值。这里指该 RDS 场景的引擎隐藏主键，不泛指所有 INVISIBLE 列。

业务列：       [id, remark_text, name, age, fr, et, kp]
Binlog 物理列：[byte_rds_ai_uk_row_id, id, remark_text, name, age, fr, et, kp]

已留存的 Binlog 解码记录中，一条 INSERT 的隐藏列值为 13，业务 id 为 15；不能把第一个物理值直接当成业务 id。若 Source 遗漏隐藏首列，按位置取值就存在整体错位的风险。
同表另一次运行的日志显示，隐藏主键可见性参数已启用，但从 Checkpoint 391 恢复的 Source Schema 仍只有 7 个业务列。这说明开启元数据可见性不等于已修正恢复状态中的 Schema。
证据范围：​以上来自 2026-09-10 的 Binlog 解码与运行日志排查；两份证据对应不同位点，未完成同一批数据的源目标逐条核对，也未验证全新初始化后的恢复结果。现有材料不是完整 E2E 测试或完整异常日志。
处置：​核对源端完整物理列、初始化或恢复后的 Source Schema。若 Schema 缺少隐藏列，不能只修改目标表或开关后直接认定恢复成功，应先确认实际解码 Schema 已包含该列，再验收字段值及历史数据。

如何区分报错与静默错列

不能简单按“类型不同就报错、类型相同就静默错列”判断。 案例二中包含字符串与数值字段，仍然发生了无异常的错误写入。是否报错取决于受影响记录经过的解码、字段访问、转换和写入环节是否拒绝当前数据。

  • 访问的列位置不存在：​可能触发行字段数量不匹配异常，案例一属于这种情况。
  • 位置存在，但数据无法按预期类型处理：​可能在解码、转换或目标写入阶段报错；不能预先断言一定是哪一种异常。
  • 位置或字段含义已经错了，但后续环节仍接受数据：​可能静默写入错值。例如两个字符串列交换位置后，类型本身无法说明值属于哪个字段；这是机制示例，不是新增复现结论。

处置：​先对齐“实际消费位点对应的表结构”和“任务使用的 Source Schema”，再检查目标结构及字段值。Online DDL 场景还应核对协议配置、工具命名和采集规则。需要回放时使用准确历史位点及配套完整 Schema，详见第 3 节；仅修正协议或目标结构不会自动修复历史错值。

2.3 DDL 语法解析失败

Source 的 DDL 解析器不支持语句中的语法时，可能在解析阶段失败。以下为真实 Connector 解析器调用的完整输出。

  • 完整报错日志：

    PARSER_ARTIFACT=file:/root/.cache/datasail-hello-world/m2/com/bytedance/bitsail/connector-cdc-mysql/0.2.0-SNAPSHOT/connector-cdc-mysql-0.2.0-SNAPSHOT.jar
DDL_BEGIN
ALTER TABLE `test`.`ddl0928_parser`
        ADD COLUMN export_ext JSON NULL COMMENT 'Export context and center recovery state',
        ADD KEY idx_export_center_reconcile ((CAST(export_ext ->> '$.mode' AS CHAR(16) CHARACTER SET utf8mb4) COLLATE utf8mb4_bin), (CAST(export_ext ->> '$.center.siteCode' AS CHAR(32) CHARACTER SET utf8mb4) COLLATE utf8mb4_bin), (CAST(export_ext ->> '$.center.syncComplete' AS UNSIGNED)), deleted, id);
DDL_END
PARSE_RESULT=FAILED
io.debezium.text.ParsingException: DDL statement couldn't be parsed. Please open a Jira issue with the statement 'ALTER TABLE `test`.`ddl0928_parser`
        ADD COLUMN export_ext JSON NULL COMMENT 'Export context and center recovery state',
        ADD KEY idx_export_center_reconcile ((CAST(export_ext ->> '$.mode' AS CHAR(16) CHARACTER SET utf8mb4) COLLATE utf8mb4_bin), (CAST(export_ext ->> '$.center.siteCode' AS CHAR(32) CHARACTER SET utf8mb4) COLLATE utf8mb4_bin), (CAST(export_ext ->> '$.center.syncComplete' AS UNSIGNED)), deleted, id);
'
no viable alternative at input 'ALTER TABLE `test`.`ddl0928_parser`\n\tADD COLUMN export_ext JSON NULL COMMENT 'Export context and center recovery state',\n\tADD KEY idx_export_center_reconcile (('
        at io.debezium.antlr.ParsingErrorListener.syntaxError(ParsingErrorListener.java:43)
        at org.antlr.v4.runtime.ProxyErrorListener.syntaxError(ProxyErrorListener.java:41)
        at org.antlr.v4.runtime.Parser.notifyErrorListeners(Parser.java:544)
        at org.antlr.v4.runtime.DefaultErrorStrategy.reportNoViableAlternative(DefaultErrorStrategy.java:310)
        at org.antlr.v4.runtime.DefaultErrorStrategy.reportError(DefaultErrorStrategy.java:136)
        at io.debezium.ddl.parser.mysql.generated.MySqlParser.sqlStatements(MySqlParser.java:1194)
        at io.debezium.ddl.parser.mysql.generated.MySqlParser.root(MySqlParser.java:922)
        at io.debezium.connector.mysql.antlr.MySqlAntlrDdlParser.parseTree(MySqlAntlrDdlParser.java:72)
        at io.debezium.connector.mysql.antlr.MySqlAntlrDdlParser.parseTree(MySqlAntlrDdlParser.java:45)
        at io.debezium.antlr.AntlrDdlParser.parse(AntlrDdlParser.java:82)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at DDLParserProbe.main(DDLParserProbe.java:14)
Caused by: org.antlr.v4.runtime.NoViableAltException
        at org.antlr.v4.runtime.atn.ParserATNSimulator.noViableAlt(ParserATNSimulator.java:2026)
        at org.antlr.v4.runtime.atn.ParserATNSimulator.execATN(ParserATNSimulator.java:467)
        at org.antlr.v4.runtime.atn.ParserATNSimulator.adaptivePredict(ParserATNSimulator.java:393)
        at io.debezium.ddl.parser.mysql.generated.MySqlParser.sqlStatements(MySqlParser.java:996)
        ... 9 more

    异常落在函数索引双括号处，完整语句同时新增 export_ext。不能只因为目标不需要索引，就把整条 ALTER 当作可忽略操作。

  • 处置：​需要同步该表或新增列时，应优先修复或升级解析能力。只有确认跳过整条语句不会遗漏所需结构变化时，才可把以下参数作为临时规避方案；日志中的 near position 不等于可直接使用的恢复位点。

    {"job":{"reader":{"debezium":{"database.history.skip.unparseable.ddl":"true"}}}}

  • 完整参数：job.reader.debezium.database.history.skip.unparseable.ddl=true。该参数作用于 Source 端 Debezium DDL Parser：遇到无法解析的 DDL 时记录 WARN 并继续运行。它不等同于 job.writer.table_operations 的“忽略变更”，也不能用 job.reader.include_schema_changes=false 替代。

  • 风险与验证：​跳过 DDL 后，Source Schema 可能没有应用该语句包含的建表、新增列或类型变化，后续 DML 仍可能因 Schema 缺失、字段数量不一致或类型不匹配而失败。仅建议在确认该 DDL 与同步表结构无关，或已通过其他方式同步 Schema 时使用；恢复后需核对 Source/目标 Schema，并验证后续 DML 字段映射和数据一致性。

3 恢复方式的选择

恢复方式

适用前提

  1. 修正配置或对齐目标结构后，从 Checkpoint 恢复。

Source 解码正确，Checkpoint 中保存的 Schema 可继续使用；必要时手工对齐目标结构，确保与任务 Schema 兼容，且不需要重放已跳过的 DDL。历史缺失或错值另行修复。

  1. 历史 Offset + 历史 Schema 回放

需要重新消费历史变更，准确位点、完整历史结构和对应 Binlog 均可取得。

  1. 临时目标表重新全量

无法安全还原历史状态，或错误范围、回放影响不可控。

  1. 临时跳过无需同步的 DDL

已确认跳过整个语句不会遗漏所需结构变化，且参数适用于实际连接器版本。

3.1 方式 2：历史 Offset + 历史 Schema 回放配置

适用于 MySQL CDC V3：从指定历史位点重新消费，并提供该位点对应的完整源表结构。开启任务的「集成高级参数设置」，配置以下参数。
以下以历史三列表 dts_test_do_not_delete_4.initial_schema_override_selftest_0819 为例。示例位点为 binlog.007898:329446，实际使用时必须替换为本任务确认的位点和当时的表结构。

  1. 指定启动方式
    参数名：job.reader.initial_offset_type；参数值：specified。

  2. 指定实际启动位点

    • 参数名：job.reader.initial_offset_props；
    • 参数值：
      {
  "file": "binlog.007898",
  "pos": "329446"
}

  3. 配置该位点对应的历史 Schema
    Image

    • 参数名：job.reader.initial_schema_overrides；
    • 参数值直接填写下面的 JSON 对象，不再包裹一层 initial_schema_overrides：
      {
  "expected_begin_offset": {
    "file": "binlog.007898",
    "pos": "329446"
  },
  "schema_overrides": [
    {
      "table_id": "dts_test_do_not_delete_4.initial_schema_override_selftest_0819",
      "target_schema": {
        "payload": "CREATE TABLE `dts_test_do_not_delete_4`.`initial_schema_override_selftest_0819` (`id` bigint NOT NULL, `name` varchar(128) DEFAULT NULL, `created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4"
      }
    }
  ]
}

    填写说明：

    • initial_offset_props 决定实际启动位置；expected_begin_offset 用于校验，应与本次启动位点一致，单独填写它不会修改消费位点。
    • table_id 填写源端的 库名.表名；target_schema.payload 虽然包含 target 字样，但填写的是该历史位点对应的完整源表 CREATE TABLE，不是目标库建表语句，也不是单条 ALTER。列顺序、类型和主键等定义应与当时结构一致。
    • 示例历史结构只有 id、name、created_at 三列。后续新增的 city 不应提前写入历史 Schema，而应由后续 Binlog 中的 ADD COLUMN 演进。
    • 多张表需要指定历史结构时，在 schema_overrides 数组中逐表添加；采集范围仍由原有采集规则决定。
      启动时选择从指定历史位点重新消费，不能仅修改上述参数后继续从旧 Checkpoint 恢复；这些参数不用于直接改写旧 Checkpoint 中保存的位点和 Schema。回放前确认对应 Binlog 仍可读取，并核对目标结构及重复写入的处理方式；回放也不会自动解决目标旧值被 DROP 清空的问题。
      无论选择哪种方式，都应分别验收：
    • 后续同步恢复：​原失败记录和恢复后的新数据写入正确，目标结构符合预期。
    • 历史数据修复：​故障期间缺失字段、错值或缺失记录已核对并补齐。
    • 恢复状态有效：​产生新的成功 Checkpoint，并确认实际启动位点和 Schema 相互匹配。
最近更新时间：2026.11.06 14:18:37
这个页面对您有帮助吗？
有用
有用
无用
无用