schema 历史主题的作用
Debezium 用 schema 历史主题记录数据源的 DDL 演进（建表、加列、改列），解析 binlog 时按历史结构还原每一行的字段布局。原因很直接：binlog 里的行事件只带列值、不带列名，解析器必须知道「这个时间点的表结构长什么样」。所以这个主题必须可持久化，并采用 compacted 清理策略保留历史版本；一旦丢失，DDL 之后的事件就会按错误的列布局解析。
基本信息
| 存什么 | 数据源的 DDL 变更序列与表结构版本 |
|---|---|
| 为什么需要 | 行镜像按当时的列布局解析，需要结构历史对齐 |
| 配置项 | schema.history.internal.kafka.topic（2.x 命名） |
| 清理策略 | compacted，由 Connect 内部主题机制维护 |
典型使用场景
- 首次接入：为每个数据源规划独立的历史主题名
- 结构演进：加列、改类型后确认历史主题已记录新版本
- 故障恢复：确认历史主题完整，避免解析列错位
- 集群迁移：内部主题要一并迁移，不能只迁业务主题
- 容量治理：评估内部主题的保留与清理策略
连接器中的相关配置
连接器中的相关配置
# 连接器配置片段
schema.history.internal.kafka.bootstrap.servers=kafka1:9092
schema.history.internal.kafka.topic=schema-changes.orderdb # 每个数据源一个主题内部主题与职责
| 主题 | 作用 | 丢失后果 |
|---|---|---|
| schema 历史主题 | 记录 DDL 与结构版本 | DDL 之后的事件解析列错位 |
| connect-offsets | 记录连接器消费位点 | 位点丢失，需按启动模式重新消费 |
| connect-configs | 保存连接器配置 | 配置丢失，需要重新提交 |
| connect-status | 保存连接器与任务状态 | 状态信息丢失，监控口径不连续 |
清理 Kafka 内部主题（connect-offsets、connect-configs、schema 历史）前，先停掉连接器并评估重建成本：内部主题不是业务数据，删了不一定能重来。
换主题名等于换一份历史：新主题里没有旧结构的记录，如果不配套做一次快照重建，新旧结构的历史会接不上，解析从切换点开始就可能错位。
一个数据源配一个历史主题是最省心的做法；把多个库的表结构记进同一个主题，虽然运行上没问题，但排查时无法按数据源隔离，也更容易在高频 DDL 场景下混淆版本顺序。