快照与增量怎么衔接
CDC 的初始快照必须与增量衔接起来：先在源端取得位点（或 GTID），再导出数据，随后从该位点继续消费，中间不能丢窗口。常见做法有三种——一致性事务导出（mysqldump --single-transaction）、短暂锁表导出、在从库上做快照；Debezium 这类工具内置了快照与位点的衔接逻辑，但仍要理解它靠什么保证一致。
基本信息
| 无锁导出 | InnoDB 加 --single-transaction，保证一致性读 |
|---|---|
| 锁表快照 | FTWRL 会阻塞写入，只适合可停写窗口 |
| 从库快照 | 在从库导出，需要承接复制延迟 |
| 工具衔接 | Debezium 等工具在 initial 快照中自带位点对齐 |
典型使用场景
- 首次接入 CDC：为历史数据做一次一致性快照
- 链路重建：位点被清理后重新初始化
- 大表迁移：分表分片逐个快照，注意各表位点一致
- 从库卸载：把快照压力放到从库，避免影响主库
- 演练验证：定期演练一次全量初始化，确认流程可用
一致性导出并携带位点
一致性导出并携带位点
# 8.0.26+ 使用 --source-data（旧名 --master-data）：导出文件头部写入位点注释
mysqldump --single-transaction --source-data=2 --databases app > app_snapshot.sql
# 打开文件头部即可看到位点信息
grep -n "CHANGE REPLICATION SOURCE" app_snapshot.sql快照方式对照
| 方式 | 保证一致的机制 | 适用与限制 |
|---|---|---|
| 无锁导出 | InnoDB 一致性读快照 | 适合多数在线表，非事务表不保证 |
| 锁表导出 | FTWRL 全局读锁 | 一致但阻塞写入，只适合停写窗口 |
| 从库快照 | 复制延迟被承接 | 卸载主库压力，位点仍是主库位点 |
| 工具内置 | 快照与位点在同一流程 | 省事，但需确认版本与参数语义 |
--single-transaction 只对 InnoDB 事务表保证一致性；MyISAM 等非事务表要评估锁表或避开业务时段，否则快照里的不同表并不在同一时刻。
顺序不能颠倒：先取位点再导出，中间产生的变更会在后续增量里补齐；反过来先导出再取位点，导出期间发生的变更两边都覆盖不到，会形成永久缺口。