Debezium中怎么對(duì)處理進(jìn)行異常

今天就跟大家聊聊有關(guān)Debezium中怎么對(duì)處理進(jìn)行異常，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

Debezium 是一個(gè)開(kāi)源CDC工具，基于Confluent的Connect平臺(tái)開(kāi)發(fā)的。Debezium是一個(gè)分布式的CDC工具，可以集成各種數(shù)據(jù)庫(kù)，設(shè)計(jì)來(lái)不會(huì)丟失任何事件。當(dāng)然，當(dāng)系統(tǒng)配置正常和運(yùn)行正常，管理正確的情況下，Debezium可以提供exactly once的數(shù)據(jù)庫(kù)事件發(fā)送。當(dāng)然，如果遇到一些系統(tǒng)問(wèn)題，也不會(huì)丟失任何數(shù)據(jù)，盡管它在故障恢復(fù)過(guò)程中，可能會(huì)產(chǎn)生幾條重復(fù)的數(shù)據(jù)。因此，一些不正常的情況下，Debezium 和 kafka會(huì)提供 at least once 事件發(fā)送。

1. Configuration and startup errors 

配置和啟動(dòng)異常

Connector組件會(huì)在啟動(dòng)的時(shí)候運(yùn)行失敗，然后在日志里面打印 error/exception日志，在一些參數(shù)異常和不能正常連接mysql的時(shí)候，停止connector?；蛘呤窃趍ysql重啟的時(shí)候，讀取binlog日志，已經(jīng)從歷史丟失，上次的binlog位置無(wú)法讀取。

這種情況，這些異常會(huì)提供一些提示操作。Connector在配置糾正和mysql問(wèn)題解決后進(jìn)行重啟。

2.MySQL becomes unavailable

當(dāng)mysql掛了

一旦Connector運(yùn)行，mysql因?yàn)槟撤N原因變得不能提供服務(wù)的時(shí)候，connetor就會(huì)停止并且退出。只要當(dāng)mysql恢復(fù)后，重啟connector即可。

注意，當(dāng)在mysql cluster 高可用環(huán)境下，使用GTID，你可以直接重啟connector。connector會(huì)自動(dòng)地從mysql server集群沖找到每臺(tái)機(jī)器的binlog，并且找回上一次讀取binglog的位置，并繼續(xù)讀取。

如果connector沒(méi)有使用GTID，那么connector的binlog記錄，只會(huì)記住它所連接的那臺(tái)mysql機(jī)器的binlog位置。所以如果要修復(fù)，也要修復(fù)對(duì)應(yīng)的那臺(tái)mysql服務(wù)器，才能提供正確的服務(wù)。

3.Kafka Connect process stops gracefully

Kafka連接處理崩潰

如果Kafka Connect在分布式模型下運(yùn)行，然后Kafka Connect突然間非正常停止。那么Kafka Connect會(huì)在shutdown之前，把當(dāng)前機(jī)器運(yùn)行的所有進(jìn)程組，遷移到其他的機(jī)器。這會(huì)導(dǎo)致短暫的數(shù)據(jù)處理延遲。

4.Kafka Connect process crashes

如果kafka Connect 崩潰，然后其他的Connector將會(huì)從之前保存的點(diǎn)，開(kāi)始重新開(kāi)始執(zhí)行。在分布式模式下，會(huì)在其他的機(jī)器自動(dòng)開(kāi)始運(yùn)行。

Connector會(huì)默認(rèn)從上次的offset開(kāi)始讀取，這回產(chǎn)生一些重復(fù)的數(shù)據(jù)，重復(fù)數(shù)據(jù)的數(shù)據(jù)量就根據(jù)上一次提交作業(yè)的差距。

PS. Debezium捕獲的event是冪等的，所以即使是有重復(fù)的數(shù)據(jù)，也會(huì)保證只會(huì)出現(xiàn)一個(gè)狀態(tài)。

5.Kafka becomes unavailable

由于所有的Connector都機(jī)會(huì)Kafka，和kafka的producer API，Kafka Connect會(huì)定期地記錄最近的offset，根據(jù)kafka Connect 的配置。

如果Kafka Broker是掛了，kafka Connector會(huì)定期地去嘗試連接 Kafka brokers.

換句話說(shuō)，如果kafka connector會(huì)在kafka broker重新運(yùn)行時(shí)進(jìn)行恢復(fù)。

6. Connector is stopped for a duration

connector 停了一段時(shí)間。

默認(rèn)情況下，Connector重啟就可以繼續(xù)連接mysql，從原本的position開(kāi)始讀取數(shù)據(jù)。

如果停的時(shí)間太久，mysql已經(jīng)把binlog給刪除掉了，那么就需要手動(dòng)配置，或者是啟動(dòng)snapshot模式。

看完上述內(nèi)容，你們對(duì)Debezium中怎么對(duì)處理進(jìn)行異常有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。