用于Apache Kafka的MongoDB连接器1.7版现已发布
今天，MongoDB发布了1.7版本的MongoDB Connector for Apache Kafka!本文重点介绍了这个新版本的一些关键功能!
MongoDB对死信队列的错误
Apache Kafka 2.6版本增加了对处理错误记录的支持。Apache Kafka的MongoDB Kafka连接器会自动将其无法处理的消息发送到死信队列中。这包括在转换过程中失败的消息，但直到这个版本都不包括在MongoDB内部产生的错误。例如，考虑这样的场景：我们有一个主题，"Sales.OrderStaging" 这个主题包括包含'order-id'字段的消息。应用程序需要向MongoDB插入一个新的文档，并使用该订单-id作为文档的主键或'_id'。如果在kafka主题上刚好有一个重复的订单-id输入，那么kafka消息应该被路由到一个死信队列主题，而mongodb连接器应该继续处理其他订单。
下面的sink配置强调了支持这种情况的配置参数：
"errors.tolerance":"all",
"mongo.errors.tolerance":"all",
"mongo.errors.log.enable":"true",
"errors.log.include.messages":"true",
"errors.deadletterqueue.topic.name":"orders.deadletterqueue",
"errors.deadletterqueue.context.headers.enable":"true",
"writemodel.strategy":"com.mongodb.kafka.connect.sink.writemodel.strategy.InsertOneDefaultStrategy",
"document.id.strategy":"com.mongodb.kafka.connect.sink.processor.id.strategy.PartialValueStrategy",
"document.id.strategy.overwrite.existing":"true",
"document.id.strategy.partial.value.projection.type": "AllowList",
"document.id.strategy.partial.value.projection.list": "order-id"
例如，考虑一个订单id=5的kafka消息和另一个订单id同样为5的消息。水槽连接器将尝试插入那个具有相同_id的第二个消息，并且会有一个MongoDB错误产生，正如预期的那样。导致错误的kafka主题消息将被写入orders.deadletterqueue主题。一旦进入死信队列，你可以检查错误的记录，更新它们，并重新提交处理。将errors.deadletterqueue.context.headers.enable设置为 "true "将向DLQ消息添加元数据。这个额外的信息可能有助于对队列中任何错误的自动处理。除了DLQ，你还可以设置errors.log.enable和error.log.include.messages配置，在kafka连接日志中写入错误。下面是我们上面场景中的一个错误例子：
com.mongodb.kafka.connect.sink.dlq.WriteException: v=1, code=11000, message=E11000 重复键错误集合。Sales.Orders index:iddup key: { _id:{ order-id:5 }}, details={}
批量写入的改进
今天，连接器的汇入过程是以有序的方式进行批量插入的。例如，考虑在一个批量操作中的这10个文件：
[1,2,3,4,5,6,7,8,9,10]
如果第5个文档失败了，也许是由于重复的_id错误，MongoDB驱动会把这个错误返回给连接器，其余的文档就不会被写入MongoDB，例如在上面的例子中，只有[1,2,3,4]被写入MongoDB。虽然这对某些用例来说可能是可以接受的，但对于其他有大批量的场景来说，这可能会使重新处理消息变得很麻烦。
在Kafka 1.7中，我们引入了一个新的参数bulk.write.ordered，默认设置为true，这是目前Kafka连接器的行为。设置为false并运行上述方案将导致[1,2,3,4,6,7,8,9,10]的最终状态被写入MongoDB，其中5被写入死信队列中定义的主题。注意，由于我们对 bulk.write.ordered 指定了 false，所以文件的实际顺序可能不同。
改变了重试逻辑
目前，Kafka连接器使用max.num.retries和retries.defer.timeout 配置属性来管理对MongoDB的重试写入。这个功能最初是为了解决网络连接问题等挑战。从那时起，MongoDB驱动程序已经实现了处理重试逻辑的本地功能。Kafka连接器使用MongoDB Java驱动程序，并且默认启用了重试功能，因此你不需要做任何改变或额外的配置来在Kafka连接器中启用重试。注意：如果你在connection.uri配置属性中把retryWrites设置为false，那么sink连接器的重试就被禁用。如果你想利用驱动程序的本地重试能力，只需从connection.uri中删除 "retryWrites"'参数。
复制时允许使用磁盘
copy.existing.allow.disk.use配置从源头复制现有数据。它使用一个聚合管道，过滤来自MongoDB源的变化流事件。在某些情况下，该管道会占用大量的内存。如果查询需要，这个默认启用的标志允许复制现有聚合使用临时磁盘存储。请注意，默认情况下是true，但如果运行MongoDB的进程没有磁盘访问的权限，则设置为false。
