Debezium 是什么
Debezium 是面向日志解析的开源 CDC 平台，以 Kafka Connect 连接器的形式读取 MySQL、PostgreSQL、Oracle、SQL Server、MongoDB 等数据源的变更日志，把行级变更转换成结构化事件投递到 Kafka。每个源表对应一个主题，事件里同时携带变更前后的行镜像与源端位点信息。
两种运行形态
常见形态是连接器跑在 Kafka Connect 集群里，事件直接进 Kafka，下游按主题订阅；另一种是 Debezium Server，独立进程把变更推送到 Kinesis、Pub/Sub、Redis 等目标，适合不想额外维护 Connect 集群的场景。前者生态更完整，后者部署更轻。
基本信息
| 定位 | 面向日志解析的开源 CDC 平台 |
|---|---|
| 运行形态 | Kafka Connect 连接器（集群）或 Debezium Server（单进程） |
| 支持源 | MySQL、PostgreSQL、Oracle、SQL Server、MongoDB、Db2 等 |
| 事件内容 | before/after 行镜像、op 变更类型、source 位点、ts_ms 时间戳 |
| 投递目标 | Kafka 主题（一表一主题），或 Server 形态直发外部目标 |
| 位点管理 | 内部主题保存 schema 历史与偏移，不能随意删除 |
典型使用场景
- 业务库变更同步到数仓 ODS，替代每日全量抽取
- 把变更分发到缓存与检索引擎，避免应用侧双写
- 微服务数据解耦：一个库的变更通过 Kafka 广播给多个下游
- 审计留痕：把变更事件写入不可变存储，支持事后追溯
- 数据库迁移期间做双跑校验：对比源库与目标的最终状态
典型数据流向
典型数据流向
# 采集端：连接器读取日志，转成事件写入主题
MySQL binlog
→ Debezium Connector（运行在 Kafka Connect）
→ Kafka 主题（每张表一个：db1.app.orders）
→ 下游：数仓 ODS / 检索索引 / 缓存 / 审计归档
# 事件按主键分区：同一主键的变更落在同一分区，保证下游按序处理
# 表结构变更（DDL）记录在内部 schema 历史主题里，供重启后解析参考提交连接器并查看状态
提交连接器并查看状态
# 通过 Kafka Connect REST 接口提交（配置见 debezium-connector-config）
curl -s -X POST http://kafka-connect:8083/connectors \
-H 'Content-Type: application/json' -d @mysql-cdc-orders.json
# 查看连接器与任务的运行状态，以及失败原因
curl -s http://kafka-connect:8083/connectors/mysql-cdc-orders/status
curl -s http://kafka-connect:8083/connectors/mysql-cdc-orders/config关键配置读法
| 配置项 | 作用 | 注意 |
|---|---|---|
| connector.class | 指定源类型连接器 | 与数据源类型必须匹配 |
| topic.prefix | 生成主题的前缀（旧名 database.server.name） | 全小写，避免特殊字符 |
| database.server.id | 以从库身份接入时使用的编号 | 每个连接器独占，不能与从库冲突 |
| table.include.list | 需要捕获的库表清单 | 范围越精确，元数据与主题数量越可控 |
| snapshot.mode | 初始快照策略 | initial 会先全量再增量，大表要评估快照时长 |
Debezium 负责把变更捕获进 Kafka，不管落目标库：需要写入数据仓库或关系库时还要配 sink 连接器或下游消费作业，两端都不做，链路就是断的。
每个连接器需要独立的 database.server.id（MySQL 源）：多个连接器共用同一个编号会让位点互相抢占，表现为事件时有时无、时断时续。