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 更改。