Mongodb

Debezium Mongodb Connector 增量快照使用

October 16, 2025
技术总结
Kafka Connect, Mongodb, Source Connector, Debezium, Incremental Snapshot

之前的博客 Kafka Connect Mongodb 反复快照 - 大数据集快照

本文中使用的 MongodbSourceConnector 是 io.debezium.connector.mongodb.MongoDbConnector 2.2.1.Final。

机制简介 #

为了提供管理快照的灵活性，Debezium 包含一个补充快照机制，称为增量快照。增量快照依赖于 Debezium 机制向 Debezium 连接器发送信号。‼️ 增量快照运行时，不会阻塞变更流事件处理。

初始快照会先保存 change stream 的位点，开始执行全量快照，全量快照完成后，再从保存的位点开始增量处理变更事件。

目前 Debezium 支持增量快照的连接器有：

  • Db2
  • MariaDB (Technology Preview)
  • MongoDB
  • MySQL
  • Oracle
  • PostgreSQL
  • SQL Server

发送这个信号支持多种方式，通过配置 signal.enabled.channels 来指定，默认为 source（也就是数据集合方式），可选值有：source、kafka、file 和 jmx：

  • source 源数据库： 配置 signal.data.collection 来指定集合
  • kafka: 配置 signal.kafka.topic 来指定 topic
  • file: 配置 signal.file 来指定文件路径，写入文件的格式数据为 JSON，字段取值参考下面的表格。
  • jmx: 启用 JMX MBean Server 来暴露 signaling bean

需要启用增量快照时，只需要向特定方式中写入数据即可。如果是 source 只需要向数据库中插入一条数据，如果是 kafka 那么则是投递一条消息。

...

Kafka + Mongodb 通信协议纪要

April 24, 2025
技术总结
Kafka, Mongodb, 协议

Kafka 和 MongoDB 是目前使用比较广泛的消息队列和数据库，在之前的很长时间里对这两个软件系统的理解都停留在概念和使用上，直到最近遇到一个“诡异”的问题，已有的经验和调试方法无法定位时，最终尝试了下抓包分析才最终定位到问题的根源。

问题描述： 使用 sarama 编写了一个 kafka 消费者组，这里不同寻常的地方在于：手动提交 + 批量消费。遇到的问题：某些分区消费进度无法成功提交，但是消息是消费成功的。出现这种情况的分区没有规律，触发 rebalance 后 “故障分区” 有概率会发生变化。

分析/定位：这里很明显的问题在于手动提交 offset 为什么不成功？从实现来说，提交 offset 的逻辑跟分区没有关系是一致，那这种不确定性故障时从哪儿来的？而且还和 rebalance 相关。 梳理下 kafka 客户端消费提交涉及到的操作：Fetch, OffsetCommit, 但是消费是正常的，那么只需要抓包分析 OffsetCommit 就可以知道 offset 提交存在什么问题。

结果： 通过抓包一切都明朗了：出现问题的分区同时有多个 OffsetCommit 请求，且其中有的请求提交的 offset 一致停留在一个 “旧的” 位置，不会更新，这样就缩小了范围：程序提交 offset 逻辑异常。

KAFKA 协议 #

Kafka 协议是基于 TCP/IP 协议的二进制协议。其结构组成如下：

struct RequestOrResponse {
    RequestResponseHeader requestResponseHeader; // uint32 messageLength;
    SpecificRequestOrResponseHeader body; // 格式取决于具体的请求和响应，比如：RequestV1Header
}

struct RequestV1Header {
  int16 apiKey;
  int16 apiVersion;
  int32 correlationId;
  string clientId;
}

协议结构 #

https://kafka.apache.org/protocol.html#protocol_messages

...

访问量 访客数