首页/数据/数据工程与 ETL 速查/CDC 与源端 DDL 变更处理
本包目录(311 条)
管道基础52 条Kafka64 条调度与编排40 条数仓建模52 条数据质量50 条
CDC 与同步53 条

CDC 与源端 DDL 变更处理

源端 DDL 是 CDC 链路的高频事故源:加列通常影响小,删列/改类型/改主键会让下游解析或写入失败;RENAME 与 TRUNCATE 在 binlog 中表现为 QUERY 事件而非行事件。落地要有“先下游兼容、再执行变更”的发布流程,工具侧只能缓解、不能替代流程。

变更类型

变更类型binlog 表现下游风险
ADD COLUMNQUERY 事件,后续行事件带新列按固定列数组解析的下游报错或丢列
DROP / RENAME COLUMNQUERY 事件按旧结构解析错位
改数据类型QUERY 事件类型不兼容写入失败
TRUNCATEQUERY 事件(无逐行 delete)目标端未同步清空,行数对不上
RENAME TABLEQUERY 事件主题与表映射失效

变更前后的核对动作

变更前后的核对动作
-- 变更前:确认当前结构与目标基线
SHOW CREATE TABLE app.orders\G
SELECT COUNT(*) FROM dw.orders;
-- 变更后:核对目标端是否出现解析/写入错误与行数偏差
常规做法是先加可空列、双写观察、再清理旧列;大促或结算窗口避免执行 DDL。

易错点

  • 以为 TRUNCATE 会生成逐行删除事件,目标端保留了一整份已清空的数据
  • 在结算窗口做 DDL,CDC 作业重放到该点时直接解析失败

数据来源与参考

  • Debezium 官方文档(DDL 与 schema 历史)
  • MySQL 8.0 官方文档(Replication / Binary Log)
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌