5.7. Debezium MySQL 连接器如何处理错误和问题
Debezium 是一个分布式系统，可捕获多个上游数据库中的所有更改，永远不会丢失或丢失事件。当系统正常运行或被仔细管理时，Debezium 会在每次更改事件记录时 完全 提供。
如果发生错误，系统将不会丢失任何事件。但是，当它从故障中恢复时，可能会重复一些更改事件。在这些异常情况下，Debebe （如 Kafka）提供 至少一次 更改事件。
详情包括在以下部分：
配置和启动错误
在以下情况下，当尝试启动时连接器会失败，在日志中报告错误或异常，并停止运行：
- 连接器的配置无效。
- 连接器无法使用指定的连接参数成功连接到 MySQL 服务器。
- 连接器试图在 binlog 中的一个位置重启，其中 MySQL 不再有可用的历史记录。
在这些情况下，错误消息包含有关此问题的详细信息，并可能会有推荐的临时解决方案。在更正配置或解决 MySQL 问题后，重启连接器。
但是，如果为高可用性 MySQL 集群启用了 GTID，您可以立即重启连接器。它将连接到集群中的不同 MySQL 服务器，找到服务器 binlog 中代表最后一个事务的位置，并开始从该特定位置读取新的服务器的 binlog。
如果没有启用 GTID，连接器会记录仅连接它的 MySQL 服务器的 binlog 位置。要从正确的 binlog 位置重启，您必须重新连接到该特定服务器。
Kafka Connect 正常停止
当 Kafka Connect 正常停止时，当 Debezium MySQL 连接器任务停止并在新的 Kafka Connect 过程中重启时，会有一个短暂的延迟。
Kafka Connect 进程崩溃
如果 Kafka Connect 崩溃，该过程会停止，并且任何 Debezium MySQL 连接器任务终止，而不记录它们最近处理的偏移量。在分布式模式中，Kafka Connect 会在其他进程中重启连接器任务。但是，MySQL 连接器从之前进程记录的最后一个偏移中恢复。这意味着，替换任务可能会在崩溃前生成一些相同的事件，从而创建重复的事件。
每个更改事件消息都包含可用于识别重复事件的源特定信息，例如：
- 事件来源
- MySQL 服务器事件时间
- binlog 文件名和位置
- GTID （如果使用）
MySQL 清除 binlog 文件
如果 Debezium MySQL 连接器停止了很长时间，MySQL 服务器会清除旧的 binlog 文件，连接器的最后位置可能会丢失。当连接器重启时，MySQL 服务器不再有起点，连接器执行另一个初始快照。如果快照被禁用，则连接器会失败，并显示错误。
有关 MySQL 连接器如何执行初始 快照的详情，请查看快照。
