4.7. Debezium MongoDB 连接器如何处理错误和问题

配置和启动错误

在以下情况下，连接器在尝试启动时失败，在日志中报告错误或异常，并停止运行：

MongoDB 变得不可用

当连接器运行后，如果任何 MongoDB 副本集的主节点不可用或无法访问，则连接器将尝试重新连接到主节点，使用 exponential backoff 来防止网络或服务器饱和。如果在可配置的连接尝试次数后主仍然不可用，则连接器将失败。

Kafka Connect 进程正常停止

如果 Kafka Connect 以分布式模式运行，并且 Kafka Connect 进程被正常停止，则在关闭该进程 Kafka Connect 之前，会将所有进程的连接器任务迁移到该组中的另一个 Kafka Connect 进程，新的连接器任务将准确获取之前的任务。在处理连接器任务时，在新进程中安全停止并重新启动时会有一个短暂的延迟。

Kafka Connect 进程崩溃

如果 Kafka Connector 进程意外停止，则运行的任何连接器任务都将终止，而不记录其最近处理的偏移。当 Kafka Connect 以分布式模式运行时，它会在其他进程中重启这些连接器任务。但是，MongoDB 连接器将从之前进程 记录 的最后偏移中恢复，这意味着新的替换任务可能会生成在崩溃前处理的一些相同更改事件。重复事件的数量取决于偏移刷新周期和数据卷在崩溃前更改。

Kafka 变得不可用

当连接器生成更改事件时，Kafka Connect 框架会使用 Kafka producer API 在 Kafka 中记录这些事件。Kafka Connect 还会定期记录您在 Kafka Connect worker 配置中指定的频率，这些事件中显示的最新的偏移量。如果 Kafka 代理不可用，运行连接器的 Kafka Connect worker 进程只会重复尝试重新连接到 Kafka 代理。换句话说，连接器任务将直接暂停，直到可以重新建立连接，此时连接器将完全恢复它们关闭的位置。

如果 snapshot.mode 设置为 initial，则连接器会在停止很长时间后失败

如果连接器被安全停止，用户可能会继续对副本设置成员执行操作。连接器离线时发生的更改将继续记录在 MongoDB 的 oplog 中。在大多数情况下，在连接器重启后，它会读取 oplog 中的偏移值，以确定每个副本集传递的最后一个操作，然后从该点恢复流更改。重启后，当连接器停止时发生的数据库操作会正常发送到 Kafka，在一段时间后，连接器会捕获数据库。连接器捕获所需的时间取决于 Kafka 的功能和性能以及数据库中发生的更改卷。

MongoDB 丢失写入

在某些情况下，MongoDB 可能会丢失提交，这会导致 MongoDB 连接器无法捕获丢失的更改。例如，如果在应用更改后的主要崩溃并记录其 oplog 的更改，则 oplog 可能会在次要节点读取其内容前不可用。因此，被选为新主节点的辅助节点可能会缺少其 oplog 中的最新更改。