6.7. Debezium MySQL 连接器如何处理错误和问题
Debezium 是一个分布式系统，用于捕获多个上游数据库中的所有更改，它不会丢失或丢失事件。当系统正常运行或谨慎管理时，Debezium 会 精确 发送每个更改事件记录。
如果出现错误，则系统不会丢失任何事件。但是，当它从错误中恢复时，可能会重复一些更改事件。在这些异常情况下，Debezium （如 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 连接器如何执行初始 快照的详情，请查看快照。
