4.7. Debezium MongoDB 连接器如何处理错误和问题
Debezium 是一个分布式系统，它捕获多个上游数据库中的所有更改，永远不会丢失或丢失事件。当系统正常运行并谨慎管理时，Debezium 会在每次更改事件时发送一次。
如果发生错误，系统将不会丢失任何事件。但是，当它从故障中恢复时，可能会重复一些更改事件。在这种情况下，Debebe （如 Kafka）提供 至少一次 更改事件。
以下主题详细介绍了 Debezium MongoDB 连接器如何处理各种错误和问题。
配置和启动错误
在以下情况下，当尝试启动时连接器会失败，在日志中报告错误或异常，并停止运行：
- 连接器的配置无效。
- 连接器无法使用指定的连接参数成功连接到 MongoDB。
失败后，连接器会尝试使用 exponential backoff 重新重新连接。您可以配置最大重新连接尝试数。
在这些情况下，这个错误将了解更多有关此问题的详细信息，并可能会有推荐的临时解决方案。当配置已被修正或已解决 MongoDB 问题时，可以重启连接器。
尝试重新连接由三个属性控制：
-
connect.backoff.initial.delay.ms- 第一次尝试重新连接前的延迟，默认值为 1 秒(1000 毫秒)。 -
connect.backoff.max.delay.ms- 尝试重新连接前的最大延迟，默认为 120 秒(120,000 毫秒)。 -
connect.max.attempts- 生成错误前的最大尝试次数，默认值为 16。
每个延迟都是之前延迟的两倍，最多延迟上限。根据默认值，下表显示每个失败的连接尝试的延迟，以及失败前的总累积时间。
| 重新连接尝试号 | 尝试前的延迟，以秒为单位 | 尝试前的总延迟，以分钟和秒为单位 |
|---|---|---|
| 1 | 1 | 00:01 |
| 2 | 2 | 00:03 |
| 3 | 4 | 00:07 |
| 4 | 8 | 00:15 |
| 5 | 16 | 00:31 |
| 6 | 32 | 01:03 |
| 7 | 64 | 02:07 |
| 8 | 120 | 04:07 |
| 9 | 120 | 06:07 |
| 10 | 120 | 08:07 |
| 11 | 120 | 10:07 |
| 12 | 120 | 12:07 |
| 13 | 120 | 14:07 |
| 14 | 120 | 16:07 |
| 15 | 120 | 18:07 |
| 16 | 120 | 20:07 |
Kafka Connect 进程安全停止
如果 Kafka Connect 以分布式模式运行，并且 Kafka Connect 进程安全停止，则在关闭 Kafka Connect 之前，会将所有进程的连接器任务迁移到那个组中的另一个 Kafka Connect 进程，新的连接器任务会完全从之前的任务停止。处理会有一个短暂的延迟，同时连接器任务安全停止并在新进程中重启。
如果组只包含一个进程，且该进程安全停止，则 Kafka Connect 将停止连接器并记录每个副本集的最后偏移量。重启后，副本集的任务将在其停止的地方继续。
Kafka Connect 进程崩溃
如果 Kafka Connector 进程意外停止，则运行的任何连接器任务都会终止，而不记录其最近处理的偏移量。当 Kafka Connect 以分布式模式运行时，它将在其他进程上重启这些连接器任务。但是，MongoDB 连接器将从之前进程 记录 的最后偏移中恢复，这意味着新的替换任务可能会生成一些在崩溃前处理的一些更改事件。重复事件的数量取决于偏移清除周期，以及数据在崩溃前更改的卷。
由于某些事件在从故障中恢复期间可能会重复，因此用户应始终预计某些事件可能会被重复。Debezium 更改是幂等的，因此一系列事件总会产生相同的状态。
Debezium 还包含在每个更改事件消息中有关事件来源的特定信息，包括 MongoDB 事件的唯一标识符(h)和时间戳(sec 和 ord)。用户可以跟踪其他这些值，以了解它是否已看到特定的事件。
如果将 snapshot.mode 设置为 initial，则连接器会在长时间停止的间隔后失败
如果连接器安全停止，用户可能会继续对副本集成员执行操作。连接器离线时发生的更改仍然记录在 MongoDB 的 oplog 中。在大多数情况下，在连接器重启后，它会读取 oplog 中的偏移值，以确定为每个副本集流传输的最后一个操作，然后恢复该点的流传输更改。重启后，连接器停止时发生的数据库操作会照常发送到 Kafka，并在一段时间后，连接器会随数据库捕获。连接器捕获所需的时间取决于 Kafka 的功能和性能以及数据库中发生的更改卷。
但是，如果连接器会长时间停止，则 MongoDB 会在连接器不活跃期间清除 oplog，从而导致连接器的最后位置丢失信息。连接器重启后，它无法恢复流，因为 oplog 不再包含以前的偏移值，用于标记连接器处理的最后一个操作。连接器也无法执行快照，因为它通常是当 snapshot.mode 属性设置为 initial 时，且没有偏移值。在这种情况下，存在不匹配，因为 oplog 不包含之前偏移的值，但连接器的内部 Kafka 偏移主题中存在偏移值。错误结果和连接器失败。
要从失败中恢复，请删除失败的连接器，并使用相同的配置创建新连接器，但使用不同的连接器名称。当您启动新的连接器时，它会执行快照以最多数据库状态，然后恢复流。
MongoDB 丢失写入
在某些情况下，MongoDB 可能会丢失提交，这会导致 MongoDB 连接器无法捕获丢失的更改。例如，如果在应用更改后的主要崩溃，并记录对 oplog 的更改，则 oplog 可能会在次要节点读取其内容前不可用。因此，选择为新主节点的二级节点可能会缺少最新的 oplog 更改。
目前，无法防止在 MongoDB 中造成这种副作用。
