衔接时序（自研方案）
衔接时序（自研方案）
① 固定位点：记录 File/Pos 或 GTID
② 全量导出：生成快照数据
③ 从固定位点开始消费增量，追平到当前
④ 校验一致后切换下游读流量| 停写窗口 | 实现简单，但对业务影响需要审批 |
|---|---|
| 锁表方案 | FTWRL 阻塞写入，仅适合可停写场景 |
| 从库快照 | 在主库压力大时优先考虑 |
| 工具内置 | 如 Debezium initial / Flink CDC 增量快照，减少自研风险 |
顺序颠倒（先导出后取位点）会永久丢失窗口内的变更，且通常要到对账时才发现。
本包目录（311 条）
管道基础52 条Kafka64 条调度与编排40 条数仓建模52 条数据质量50 条
CDC 与同步53 条
- MySQL binlog 二进制日志基础
- Debezium：Kafka Connect 上的 CDC
- CDC 变更数据捕获：概念与实现方式
- Flink CDC：把 CDC 做成 Flink 连接器
- Debezium MySQL 连接器配置
- binlog 三种格式：ROW/STATEMENT/MIXED
- Canal：伪装从库的增量订阅
- DataX：批式数据同步与 job.json
- Debezium 事件结构与 op 字段
- Flink SQL 声明 MySQL CDC 源表
- binlog_row_image：行镜像粒度
- 开启 binlog：my.cnf 配置要点
- Debezium snapshot.mode 快照模式
- SHOW MASTER STATUS：查看 binlog 位点
- mysqlbinlog：解析与导出 binlog
- GTID：全局事务标识符
- PURGE BINARY LOGS：清理 binlog
- CDC 账号权限清单
- Debezium schema 历史主题
- flink-cdc scan.startup.mode 启动模式
- 幂等落库：主键 upsert
- binlog 保留期与 binlog_expire_logs_seconds
- CDC 断链：找不到 binlog 文件
- Kafka Connect worker 配置要点
- Flink CDC 与 checkpoint 位点提交
- 全量与增量衔接方案
- CDC 快照一致性：位点与导出衔接
- Canal 部署与 instance 配置
- Debezium 位点存储与重置
- CDC 与源端 DDL 变更处理
- 同步积压排查路径
- SHOW BINARY LOGS：日志文件清单
- Flink CDC YAML 管道：整库同步
- Sqoop 增量导入与退出维护
- 源目标对账校验方法
- 回补与重放的设计要点
- binlog 事件类型速查
- GTID 与位点方式对比
- Canal 投递 Kafka 配置
- DataX 限流与错误控制
- CDC 落 Kafka 的主题设计
- CDC 落湖仓：主键 merge 与乱序处理
- CDC 与同步工具选型对照
- CDC 进数仓的落地方式
- PostgreSQL 逻辑复制与复制槽
- Debezium 监控指标
- Maxwell：轻量 binlog JSON 输出
- 重放去重：至少一次语义兜底
- 删除语义：物理删除与逻辑删除同步
- 位点滞后监控设计
- Oracle CDC：LogMiner 与补充日志
- Canal HA：ZooKeeper 主备
- Canal client 拉取与位点确认
全量与增量衔接方案
开荒同步的关键是全量与增量的衔接点：常见方案有停写窗口、锁表拿位点、从库做快照，以及工具内置的“快照 + 位点衔接”（Debezium initial 快照、Flink CDC 增量快照）。自研方案必须固定位点在前、全量导出在后，再从该位点追平。
易错点
- 全量追赶期间不做限速，回放把目标库 IO 打满
- 追平阶段没监控消费速率，不知道何时可以切换流量
数据来源与参考
- Debezium 官方文档（initial snapshot 机制）
- Flink CDC 官方文档（增量快照算法）