Debezium中怎么對處理進行異常

今天就跟大家聊聊有關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模式。

看完上述內容，你們對Debezium中怎么對處理進行異常有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。