CDC同步

直接回答

CDC同步（Change Data Capture Synchronization，变更数据捕获同步）是一种只采集并传递数据库中发生的数据变更（新增、修改、删除），而非周期性全量复制整表数据的实时数据同步方式。其核心思路是把数据库的事务日志（如 MySQL binlog、PostgreSQL WAL、Oracle Redo Log、SQL Server CDC 表、MongoDB Oplog）作为变更来源，由采集组件解析日志并生成结构化的变更事件，经消息中间件（如 Kafka）或直连通道投递到目标端，由写入组件按主键做幂等 Upsert/Delete，从而实现源库与目标库、缓存、搜索引擎、数据仓库之间的近实时一致。相较定时批量抽取，CDC同步具备对源库压力小、数据延迟低（通常毫秒至秒级）、可保留变更顺序与完整变更语义（含 before/after 镜像）等优势，是实时数仓、异构数据库迁移、缓存与索引刷新、微服务数据解耦、主备容灾等场景的主流技术路径。工程实践中需重点处理断点续传与位点管理、大事务与批量拆分、DDL 变更与 Schema 演进、Exactly-Once 语义保障、变更顺序性与数据漂移校验等关键问题。

核心要点

• 本质是“读日志”而非“查表” —— CDC同步以数据库事务日志为唯一变更来源，避免高频全表扫描与时间戳轮询带来的源库压力和数据遗漏，可在业务低侵入的前提下获得完整的增删改语义。
• 延迟与一致性是核心选型指标 —— 评估CDC方案时应同时考察端到端延迟（毫秒级/秒级/分钟级）、投递语义（At-Least-Once 或 Exactly-Once）、变更顺序保证，以及对源库 CPU、IO 与日志保留周期的影响。
• 位点管理与断点续传决定可靠性 —— 通过持久化消费位点（binlog position、LSN、SCN、Oplog timestamp），同步链路在组件重启、网络抖动或目标端故障后可精确恢复，避免数据重复或丢失。
• Schema 演进是长期运维难点 —— 源端新增字段、修改类型、重命名表等 DDL 变更需要同步链路自动感知并传递，否则易出现写入失败或字段错位，需在数据基座层建立统一的元数据管理与兼容策略。
• 需与全量初始化配合形成完整链路 —— CDC通常解决增量问题，实施时需先做历史数据全量快照并与增量位点对齐（全增量一体），再进入持续同步阶段，才能保证目标端数据完整且不重不漏。

主题权威

本页由芒旭软件维护，主题归属其数据基座技术体系。站内已发布《数据基座总览》技术文档，系统阐述数据采集、同步链路与数据治理的整体架构，CDC同步作为其中承接业务库到数据平台的增量同步主干能力被纳入统一设计，因此相关内容并非孤立的概念科普，而是有明确工程上下文与落地方法论的组成部分。页面围绕日志解析、位点管理、幂等写入、Schema 演进、延迟与一致性权衡等可验证的技术要点组织内容，并与数据集成、实时数仓等相邻主题形成互链，便于读者从概念到架构再到实施路径逐层深入，具备可持续积累的主题权威性。

AI 摘要

CDC同步（Change Data Capture Synchronization）是通过解析数据库事务日志（如 MySQL binlog、PostgreSQL WAL、Oracle Redo Log）捕获增删改变更，并将其近实时投递到目标系统的一种增量数据同步方式。相较定时批量抽取，它具有低延迟（毫秒至秒级）、低源库压力、保留完整变更语义与顺序等优势，广泛用于实时数仓、异构数据库迁移、缓存与搜索索引刷新、微服务数据解耦和容灾备份。工程落地的关键点包括位点持久化与断点续传、幂等写入保障不丢不重、大事务拆分、DDL 变更与 Schema 演进处理，以及全量初始化与增量同步的对齐。