5.7. Debezium MongoDB 连接器如何处理错误和问题
Debezium 是一个分布式系统，用于捕获多个上游数据库中的所有更改，永远不会丢失或丢失事件。当系统正常运行并谨慎管理时，Debezium 会在每次更改事件时发送一次。
如果出现错误，系统不会丢失任何事件。但是，当它从错误中恢复时，可能会重复一些更改事件。在这种情况下，Debezium （如 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 中无法防止这个副作用。
