Kafka Connect

Debezium Mongodb Connector 增量快照使用

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

本文中使用的 MongodbSourceConnectorio.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 MirrorMaker2 从使用到迁移

本文中使用的 Kafka 版本为 v3.3.2

引言 #

Kafka MirrorMaker2 是 Kafka 官方提供的跨集群数据复制工具, 它是基于 Kafka Connect 框架构建的。MirrorMaker2 支持多种部署模式, 包括 Dedicated 模式和 Connect 集群模式,还有 standalone 模式。

其中, Dedicated 模式有一个启动脚本 kafka-mirror-maker.sh, 该脚本会启动一个独立的 MirrorMaker2 实例, 而不需要依赖 Kafka Connect 集群。Dedicated 模式适合小规模的复制任务, 但在大规模部署中, 它缺乏可扩展性和高可用性。

相比之下, Connect 集群模式则是先搭建出一个 Kafka Connect 集群, 再提交 MirrorMaker2MirrorSourceConnector 任务。这种模式下, 可以通过增加或减少 Connect 工作节点来动态调整复制任务的资源, 具备更好的弹性和容错能力。

当然配置上也会更复杂一些, 需要管理 Connect 集群的配置和任务。

那么, 如果我们已经在使用 Dedicated 模式部署了 MirrorMaker2, 但现在需要切换到 Connect 集群模式, 应该如何操作呢? 本文将介绍从 Dedicated 模式迁移到 Connect 集群模式时,怎么处理已经同步的 offset 进度, 以确保数据的一致性和连续性。

...

近期的一些经验总结

这里不会过多的介绍软件的相关概念和架构,主要是针对实际问题的解决方案和思考。

问题汇总 #

访问量 访客数