CDC 全量快照和增量日志怎么无缝衔接？
面试怎么回答
CDC 初始化要把一致性快照和日志位置绑定起来，保留快照期间的更新与删除，再按连接器支持的规则衔接。并行分块还要处理重叠窗口，避免旧快照覆盖新日志或复活删除行。恢复时同时管理快照进度、日志位点和目标持久化状态，验收在同一边界核对主键与字段，日志保留期必须覆盖初始化及恢复时间。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
“先把全表查出来，再从当前位点订阅日志。”这听起来像一个完整的初始化方案，但全表扫描过程中发生的修改要算在哪一段？如果这段边界没有定义，快照越久，风险窗口越大。
快照读取必须与日志位置建立一致边界，快照期间的变化需要保留并正确合并；恢复依赖快照进度、日志位点和目标端版本规则共同工作。
扫描全表的同时，源表仍然在变化
一张大表可能扫描很久，开始读和结束读之间会有插入、更新、删除。若扫描结束后才从那一刻的日志位点开始消费，已经扫描过的记录在扫描期间发生的变化可能永远没有机会进入目标表。
因此“读到了所有主键”并不等于读到了某个一致时点的完整状态。要先确认数据库能够提供什么一致性快照，以及连接器怎样把这个快照和日志位置对应起来。不同数据库与连接器的实现步骤不能机械混用。
一致性快照方案要绑定可恢复的日志位置
一种典型思路是在连接器支持的锁或一致性机制下，建立快照视图并记录与之匹配的日志位置，完成快照后再从对应位置继续处理变化。短暂锁定的对象和持续时间，取决于数据库和快照模式。
这里重要的是边界契约，而不是背一个固定步骤。需要查清快照是否全库一致、DDL 如何处理、长事务怎样影响可见性，以及日志保存时间是否覆盖扫描和故障恢复所需的周期。
分块快照需要处理每个块的重叠窗口
并行分块可以减少初始化时间，但每个块读取期间仍然可能变化。支持增量快照的连接器可能使用高低水位、缓冲与去重机制，把块内读取结果和同期变更归并；水位具体含义应以所用实现为准。
不能把所有快照行简单地先后覆盖到目标表。若日志已经把某行更新为新版本，之后到达的旧快照行又覆盖回去，最终状态就会倒退。删除事件也必须参与合并，否则已删除记录可能被旧快照复活。
一个典型场景：行数正确，字段仍停在旧值
比如目标表初始化完成后总行数与源表一致，抽查却发现少量订单状态过期。最初怀疑下游缓存，追踪同一主键的事件序列才看到：增量更新先写入，旧快照后写入。
原检查只比较数量，没有验证同一位点下的字段状态。修复应优先使用连接器保证的快照与日志衔接机制，目标侧按可靠的来源版本处理覆盖，并增加快照中修改、删除、失败重启的测试，不能靠修改时间碰运气排序。
恢复不仅是记住一个 Offset
初始化期间宕机，需要知道快照处于哪个阶段、哪些块完成、增量处理到哪里，以及目标写入是否已经持久化。若源日志已过期，继续使用旧位点可能根本无法恢复，必须按既定流程重新初始化或补偿。
上线验收可以冻结一个可比较的业务批次或日志边界，核对主键集合、关键字段、删除和重复情况。长期监控快照进度、日志保留余量、消费延迟与目标版本倒退，才算把初始化和常态消费真正接起来。