Debezium 位点存在哪
Debezium 的消费位点存在 Kafka Connect 的 offset 存储主题（默认 connect-offsets）里，内容包括 binlog 文件名与偏移，或 GTID 与事务信息。连接器重启后从该位点继续消费，不会重新做快照。位点按源端实例标识区分，所以更换实例标识会被当作新环境处理，直接触发一次新的快照。
基本信息
| 存储位置 | Kafka Connect 的 offset.storage.topic，默认 connect-offsets |
|---|---|
| 内容 | 连接器位点：文件名与偏移、或 GTID 与事务信息 |
| 重启行为 | 从上次位点继续，不重新做快照 |
| 重置方式 | 删除连接器后重建并选择快照模式，或按官方工具调整位点 |
典型使用场景
- 连接器重启验证：确认是位点续传而不是重新快照
- 误删位点：评估是全量重来还是能找回原来的位点
- 更换实例标识：确认是否会被当成新环境触发快照
- 迁移演练：把位点主题一起迁移并验证续传
- 故障排查：通过 REST 接口查看连接器与任务状态
查看状态与位点主题
查看状态与位点主题
# 查看连接器与任务状态
curl -s http://kafka-connect:8083/connectors/mysql-cdc-orders/status
# 查看 offset 主题内容（只读排查，不要手改生产）
kafka-console-consumer.sh --bootstrap-server kafka1:9092 \
--topic connect-offsets --from-beginning --property print.key=true | head位点相关行为
| 操作 | 结果 | 风险 |
|---|---|---|
| 重启连接器 | 从已提交位点续读 | 不会跳过数据 |
| 删除并重建连接器 | 按新配置重新开始 | 可能重做快照或重复消费 |
| 删除 offset 记录 | 位点丢失 | 退化为重新快照 |
| 更换源端实例标识 | 被当作新环境 | 触发一次新的快照流程 |
直接手改 connect-offsets 很容易写坏 JSON 结构，导致连接器无法启动；需要重置时优先走「删除并重建连接器加选择快照模式」的标准路径。
重建连接器时如果不清理旧位点，它会自动续跑到原位，想着重放历史却往往得不到预期结果；重建前先明确是「续传」还是「重来」。
位点主题里同时保存着多个连接器的记录，按连接器名与源端标识分组；迁移环境时如果只复制了业务主题而漏掉位点主题，新环境会从启动模式重新开始，表现为一次意外的全量快照。