破案了....

直接跳到末尾：

讀者福利 贈4本書籍!

有人報案

最近技術(shù)群里面有幾個同學(xué)碰到了 刪除Topic的問題, 怎么樣也刪除不掉,然后我協(xié)助排查之后,就做個記錄,寫篇文章,大家在碰到這類型的問題的時候應(yīng)該怎么去排查

收集線索

報not retrying deletion 異常

版本:kafka_2.11-2.0.0

刪除前在執(zhí)行重分配,但是失敗了,強制停止數(shù)據(jù)遷移,手動刪除了節(jié)點/admin/reassign_partitions

再次重新刪除提示異常Topic test is already marked for deletion

所有Broker均在線

delete.topic.enable=true

檢查了每個Broker都沒有副本被刪除,甚至也沒有被標(biāo)記為--delete

調(diào)查線索

從我們收集到的線索來看,有兩個突破口

not retrying deletion

Topic test is already marked for deletion

我們先看,第2個突破口,打開kafka_2.11-2.0.0源碼,全局搜索關(guān)鍵字is already marked for deletion

這個表示,你已經(jīng)標(biāo)記了這個topic刪除了, 在zk上寫入了節(jié)點/amin/delete_topics/{topicName}

上面收集線索時候我們知道是它重新執(zhí)行刪除的時候拋出的異常,說明zk節(jié)點已經(jīng)寫入了,已經(jīng)準(zhǔn)備刪除了;

這里沒有什么問題

問題在于為什么沒有執(zhí)行刪除呢？

所以下一個突破口就在于

通過源碼我們可以看到,出現(xiàn)了這個異常表示的是：

當(dāng)前這個topic不符合重試刪除的條件

在刪除隊列topicsToBeDeleted里面；這個隊列是從zk節(jié)點/amin/delete_topics獲取的數(shù)據(jù)

當(dāng)前還未開始對該Topic進題刪除; 判定條件是沒有副本處于開始刪除的狀態(tài)「ReplicaDeletionStarted」(當(dāng)然如果delete.topic.enable=false這條肯定滿足)

主題沒有被標(biāo)記為不符合刪除條件; 不符合刪除條件的都保存在topicsIneligibleForDeletion

抽絲剝繭,接近真相

上面的3個條件,通過對方了解到

/amin/delete_topics 節(jié)點下面有數(shù)據(jù),

線索排除

讓對方查詢了Deletion started for replicas這個日志,日志表示的是哪些副本狀態(tài)變更成

「開始刪除」

,日志有查詢到如下

然后讓查詢Dead Replicas (%s) found for topic %s (這個表示的是哪些副本離線了) 也查詢到如下

從日志,和源碼我們可以得出,Not retrying deletion of topic 的原因是:

刪除流程已經(jīng)開始,但是存在離線的或不可用的副本

，哪些副本異常,從上面的Dead Replicas (%s) found for topic %s 的日志可以得知, 既然知道了原因,那么解決方案：

聚焦副本為何離線了,讓副本恢復(fù)正常就行了

不過這里我們還有再重點說一下第3種情況

前面2個說完了,接著說一下topicsIneligibleForDeletion到底是什么,什么情況下才會放到這里面來呢？

Controller初始化的時候判斷條件

kafka_2.11-2.0.0 沒有這個步驟

數(shù)據(jù)正在遷移中

判斷數(shù)據(jù)是否在遷移中是通過判斷topic的是否存在要新增或者刪除的副本, 查詢/brokers/topics/{topicName}節(jié)點中有沒有這兩個屬性值

topic副本所在Broker有宕機導(dǎo)致的副本不在線

副本所在的數(shù)據(jù)目錄log.dirs存在脫機磁盤

運行中判斷條件

發(fā)起的StopReplica 請求返回異常,加入不符合刪除條件

刪除的過程中,發(fā)現(xiàn)該Topic 有副本重分配的操作 則加入不符合刪除條件

刪除的過程,有副本下線了,則加入不符合刪除條件

開始執(zhí)行副本重分配的操作, 則加入不符合刪除條件

結(jié)案

經(jīng)過深入源碼排查走訪,我們基本上確定了問題的根源

副本離線,導(dǎo)致的刪除流程不能完成; 通過查詢?nèi)罩?也鎖定了那些個嫌疑犯,好家伙還是團伙作案

最后的解決方案也很粗暴,找到副本不正常的那幾臺Broker,

重啟

…之后副本瘋狂同步(其他一些topic數(shù)據(jù)同步);最終topic正常刪除了

排查手冊

為了以后出現(xiàn)同樣類似的問題,我總結(jié)了一下問題的排查手段,給大家指明一條思路;

快速破案

確保 delete.topic.enable=true ;配置文件查詢

確保當(dāng)前該topic沒有進行

「副本重分配」

, 查詢zk節(jié)點/admin/reassign_partitions的值是否有該topic、或者 節(jié)點/brokers/topics/{topicName}節(jié)點里面的屬性adding_replicas、removing_replicas有沒有值

確保所有副本所屬Broker均在線

確保副本均在線, (Broker在線并且log.dirs沒有脫機), 搜日志"Dead Replicas " 關(guān)鍵字查詢到哪些副本異常

解放方案

根據(jù)上面的排查順序,對應(yīng)不同的解決方案;

如果正在進行

「副本重分配」

那么等待分配完成就可以正常刪除了

如果是副本不在線,那么就去解決為啥不在線,該重啟就重啟

幕后黑手

這就完了嗎？

「log.dir為什么會脫機呢?」

「脫機跟數(shù)據(jù)遷移有關(guān)系嗎?」

根據(jù)以往的問題,好像數(shù)據(jù)遷移總是會伴隨著一些刪除上的問題

導(dǎo)致數(shù)據(jù)目錄脫機的原因的最終BOSS是

「副本重分配」

嗎？

留下懸念, 下期再見!

Kafka 運維

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。