[翻译]Debezium如何处理异常

Debezium 是一个开源CDC工具，基于Confluent的Connect平台开发的。

这里翻译一下，官方文档是怎么描述对于异常处理的。

 

Debezium是一个分布式的CDC工具，可以集成各种数据库，设计来不会丢失任何事件。当然，当系统配置正常和运行正常，管理正确的情况下，Debezium可以提供exactly once的数据库事件发送。当然，如果遇到一些系统问题，也不会丢失任何数据，尽管它在故障恢复过程中，可能会产生几条重复的数据。因此，一些不正常的情况下，Debezium 和 kafka会提供 at least once 事件发送。

 

1. Configuration and startup errors 

配置和启动异常

Connector组件会在启动的时候运行失败，然后在日志里面打印 error/exception日志，在一些参数异常和不能正常连接mysql的时候，停止connector。或者是在mysql重启的时候，读取binlog日志，已经从历史丢失，上次的binlog位置无法读取。

这种情况，这些异常会提供一些提示操作。Connector在配置纠正和mysql问题解决后进行重启。

 

2.MySQL becomes unavailable

当mysql挂了

一旦Connector运行，mysql因为某种原因变得不能提供服务的时候，connetor就会停止并且退出。只要当mysql恢复后，重启connector即可。

注意，当在mysql cluster 高可用环境下，使用GTID，你可以直接重启connector。connector会自动地从mysql server集群冲找到每台机器的binlog，并且找回上一次读取binglog的位置，并继续读取。

如果connector没有使用GTID，那么connector的binlog记录，只会记住它所连接的那台mysql机器的binlog位置。所以如果要修复，也要修复对应的那台mysql服务器，才能提供正确的服务。

3.Kafka Connect process stops gracefully

Kafka连接处理崩溃

如果Kafka Connect在分布式模型下运行，然后Kafka Connect突然间非正常停止。那么Kafka Connect会在shutdown之前，把当前机器运行的所有进程组，迁移到其他的机器。这会导致短暂的数据处理延迟。

4.Kafka Connect process crashes

如果kafka Connect 崩溃，然后其他的Connector将会从之前保存的点，开始重新开始执行。在分布式模式下，会在其他的机器自动开始运行。

Connector会默认从上次的offset开始读取，这回产生一些重复的数据，重复数据的数据量就根据上一次提交作业的差距。

PS. Debezium捕获的event是幂等的，所以即使是有重复的数据，也会保证只会出现一个状态。

5.Kafka becomes unavailable

由于所有的Connector都机会Kafka，和kafka的producer API，Kafka Connect会定期地记录最近的offset，根据kafka Connect 的配置。

如果Kafka Broker是挂了，kafka Connector会定期地去尝试连接 Kafka brokers.

换句话说，如果kafka connector会在kafka broker重新运行时进行恢复。

6. Connector is stopped for a duration

connector 停了一段时间。

默认情况下，Connector重启就可以继续连接mysql，从原本的position开始读取数据。

如果停的时间太久，mysql已经把binlog给删除掉了，那么就需要手动配置，或者是启动snapshot模式。

 

ref: https://debezium.io/docs/connectors/mysql/#when-things-go-wrong

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

转载于:https://my.oschina.net/dacoolbaby/blog/3073759