断点是某条变更事件的唯一标识未被消费，如mysql的file_name+position、debezium的source.offset、oracle的scn；需通过元数据表存储offset与主键并查询max(offset)恢复，禁止依赖时间戳或count对比。
同步中断后怎么准确定位断点位置
断点不是“某个时间点”，而是“某条变更事件的唯一标识未被消费”。mysql binlog 里是 file_name + position，debezium kafka 消息里是 source.offset 字段，oracle logminer 则依赖 scn。靠人工查日志或比对时间戳基本不可靠——网络延迟、事务提交顺序、多线程写入都会让时间不具可比性。
实操建议：
- 所有 CDC 同步任务必须开启
include.transaction.details=true（Debezium）或等效配置，确保每条消息携带事务边界和源库位点 - 目标端写入前，先将
source.offset和当前记录主键（如id或event_id）一起存入一张轻量级元数据表（如sync_checkpoint），带唯一索引 - 中断恢复时，不查“最后一条成功数据的时间”，而是查
SELECT MAX(offset) FROM sync_checkpoint WHERE status = 'success'，直接跳到该 offset 继续消费 - 避免用
SELECT COUNT(*)对比源/目标总条数来定位断点——它只能告诉你“不对”，不能告诉你“从哪开始不对”
测试库与生产库断点续传必须隔离存储状态
测试库常被反复重建、快照回滚，如果和生产库共用同一套 checkpoint 存储（比如同一个 Kafka topic 的 consumer group、同一张 sync_checkpoint 表），一次测试环境重置就可能把生产同步位点覆盖或清空，导致重复同步甚至主键冲突。
实操建议：
- 为测试同步单独分配 consumer group ID，例如
cg-test-inventory-sync-v2，绝不用cg-prod-*的命名空间 - 测试库的 checkpoint 表名加环境前缀：
test_sync_checkpoint，字段结构与生产一致但物理隔离 - 使用
Testcontainers启动测试数据库时，通过withInitScript()自动初始化独立 checkpoint 表，避免手动误操作 - 禁止在测试脚本中执行
DELETE FROM sync_checkpoint类语句——哪怕加了WHERE env = 'test'，也容易因条件漏写酿成事故
无损发布时如何验证断点续传真正生效
很多团队以为“配置了 offset 提交”就等于“支持断点续传”，结果上线后发现：服务重启后从头拉取、K8s Pod 重建后丢失位点、跨 AZ 故障切换后数据重复。根本原因是状态没落盘，或落盘后没做一致性校验。
实操建议：
- 启用 Kafka 的
enable.auto.commit=false，改用commitSync()手动提交，并在 commit 成功后，立刻向 checkpoint 表写入同一位点，再返回 success 响应 - 每次启动同步服务时，强制执行一次“位点自检”：
SELECT * FROM sync_checkpoint WHERE offset > (SELECT MAX(offset) FROM source_log_position)，若存在则告警并暂停同步 - 在灰度发布阶段，对首批 100 条变更记录开启双写验证：同时写进目标库和一张
audit_log表，字段含source_offset、target_write_time、is_duplicate，用脚本自动比对 - 不要依赖监控图表上的“延迟毫秒数”判断是否无损——那只是消息队列积压，不反映位点是否真实提交
更新同步逻辑时怎么避免断点失效
给同步程序加新字段映射、改过滤条件、升级 Debezium 版本……这些看似安全的操作，极可能让旧位点无法解析新消息结构，导致反序列化失败、跳过事件、甚至阻塞整个 pipeline。
实操建议：
- 任何代码变更前，先备份当前
source.offset和对应 Binlog 文件内容（用mysqlbinlog --base64-output=DECODE-ROWS -v抽样检查） - 新增字段映射必须兼容 null：目标表字段设为
NULLABLE，同步逻辑里用row.get("new_col") != null ? row.get("new_col") : defaultValue，而非直接row.get("new_col") - 升级 CDC 工具版本时，务必查阅 Release Note 中关于
offset schema的变更说明——Debezium 2.3 升 2.4 就调整过snapshot阶段的 offset 格式，老位点无法识别 - 上线后 5 分钟内，必须人工核对至少一条带新字段的记录是否完整写入，不能只看日志里有没有 ERROR
断点续传真正的难点不在“怎么记”，而在“记下来之后，谁信它、怎么用、坏了怎么修”。状态存储的位置、格式、生命周期，必须和业务发布节奏、环境治理策略、故障响应流程对齐——否则再漂亮的 SDK 配置，也只是一层薄纸。
