本文主要是介绍Debezium日常分享系列之：Debezium2.5稳定版本之处理常见问题，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
Debezium日常分享系列之：Debezium2.5稳定版本之处理常见问题
- 一、配置和启动错误
- 二、MySQL 不可用
- 三、Kafka Connect stops gracefully
- 四、Kafka Connect 进程崩溃
- 五、Kafka变得不可用
- 六、MySQL 清除 binlog 文件
- 七、Debezium技术总结
下面描述 Debezium 如何处理各种故障和问题。
- Debezium从入门到精通系列之：百篇系列文章汇总之研究Debezium技术遇到的各种错误的解决方法
Debezium是一个分布式系统，可以捕获多个上游数据库中的所有变化；它永远不会错过或丢失任何事件。当系统正常运行或受到仔细管理时，Debezium 会提供每个变更事件记录的一次性交付。
如果确实发生故障，系统不会丢失任何事件。然而，当它从故障中恢复时，它可能会重复一些更改事件。在这些异常情况下，Debezium 与 Kafka 一样，提供至少一次变更事件的传递。
一、配置和启动错误
在以下情况下，连接器在尝试启动时失败，在日志中报告错误或异常，并停止运行：
- 连接器的配置无效。
- 连接器无法使用指定的连接参数成功连接到 MySQL 服务器。
- 连接器正尝试在 MySQL 不再具有可用历史记录的 binlog 中的位置重新启动。
在这些情况下，错误消息包含有关问题的详细信息以及可能的建议解决方法。更正配置或解决 MySQL 问题后，重新启动连接器。
二、MySQL 不可用
如果您的 MySQL 服务器不可用，Debezium MySQL 连接器将失败并出现错误，并且连接器将停止。当服务器再次可用时，重新启动连接器。
但是，如果为高可用 MySQL 集群启用了 GTID，您可以立即重新启动连接器。它将连接到集群中的不同 MySQL 服务器，在服务器的 binlog 中查找代表最后一个事务的位置，并开始从该特定位置读取新服务器的 binlog。
如果未启用 GTID，连接器将仅记录其所连接的 MySQL 服务器的 binlog 位置。要从正确的二进制日志位置重新启动，您必须重新连接到该特定服务器。
三、Kafka Connect stops gracefully
当 Kafka Connect 正常停止时，Debezium MySQL 连接器任务在新的 Kafka Connect 进程上停止并重新启动时会出现短暂的延迟。
四、Kafka Connect 进程崩溃
如果 Kafka Connect 崩溃，进程将停止，所有 Debezium MySQL 连接器任务也会终止，且不会记录最近处理的偏移量。在分布式模式下，Kafka Connect会重新启动其他进程上的连接器任务。但是，MySQL 连接器从早期进程记录的最后一个偏移量开始恢复。这意味着替换任务可能会生成一些在崩溃之前处理的相同事件，从而创建重复事件。
每条更改事件消息都包含特定于源的信息，您可以使用这些信息来识别重复事件，例如：
- 事件起源
- MySQL服务器的事件时间
- binlog文件名和位置
- GTID（如果使用）
五、Kafka变得不可用
Kafka Connect 框架使用 Kafka 生产者 API 记录 Kafka 中的 Debezium 更改事件。如果 Kafka 代理不可用，Debezium MySQL 连接器将暂停，直到重新建立连接并且连接器从中断处恢复。
六、MySQL 清除 binlog 文件
如果 Debezium MySQL 连接器停止时间过长，MySQL 服务器会清除旧的二进制日志文件，并且连接器的最后位置可能会丢失。当连接器重新启动时，MySQL 服务器不再具有起始点，连接器将执行另一个初始快照。如果禁用快照，连接器将失败并出现错误。
七、Debezium技术总结
更多Debezium技术请参考：
- Debezium技术专栏
这篇关于Debezium日常分享系列之：Debezium2.5稳定版本之处理常见问题的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
