直接跳到末尾：讀者福利 贈4本書籍!
🔥《Kafka運維管控平臺》🔥 ??更強大的管控能力?? 🎾更高效的問題定位能力🎾 🌅更便捷的集群運維能力🌅 🎼更專業的資源治理🎼 🌞更友好的運維生態🌞
有人報案
最近技術群里面有幾個同學碰到了 洗掉Topic的問題, 怎么樣也洗掉不掉,然后我協助排查之后,就做個記錄,寫篇文章,大家在碰到這型別的問題的時候應該怎么去排查
收集線索
- 報
not retrying deletion例外 - 版本:
kafka_2.11-2.0.0 - 洗掉前在執行重分配,但是失敗了,強制停止資料遷移,手動洗掉了節點
/admin/reassign_partitions - 再次重新洗掉提示例外
Topic test is already marked for deletion - 所有Broker均在線
delete.topic.enable=true- 檢查了每個Broker都沒有副本被洗掉,甚至也沒有被標記為
--delete
調查線索
從我們收集到的線索來看,有兩個突破口
not retrying deletionTopic test is already marked for deletion
我們先看,第2個突破口,打開kafka_2.11-2.0.0原始碼,全域搜索關鍵字is already marked for deletion
這個表示,你已經標記了這個topic洗掉了, 在zk上寫入了節點/amin/delete_topics/{topicName}
上面收集線索時候我們知道是它重新執行洗掉的時候拋出的例外,說明zk節點已經寫入了,已經準備洗掉了;
這里沒有什么問題
問題在于為什么沒有執行洗掉呢？
所以下一個突破口就在于
通過原始碼我們可以看到,出現了這個例外表示的是：當前這個topic不符合重試洗掉的條件
- 在洗掉佇列
topicsToBeDeleted里面；這個佇列是從zk節點/amin/delete_topics獲取的資料 - 當前還未開始對該Topic進題洗掉; 判定條件是
沒有副本處于開始洗掉的狀態「ReplicaDeletionStarted」(當然如果delete.topic.enable=false這條肯定滿足) - 主題沒有被標記為不符合洗掉條件; 不符合洗掉條件的都保存在
topicsIneligibleForDeletion
抽絲剝繭,接近真相
上面的3個條件,通過對方了解到
-
/amin/delete_topics節點下面有資料, 線索排除 -
讓對方查詢了
Deletion started for replicas這個日志,日志表示的是哪些副本狀態變更成「開始洗掉」 ,日志有查詢到如下
然后讓查詢Dead Replicas (%s) found for topic %s(這個表示的是哪些副本離線了) 也查詢到如下
從日志,和原始碼我們可以得出,Not retrying deletion of topic的原因是: 洗掉流程已經開始,但是存在離線的或不可用的副本 ，哪些副本例外,從上面的Dead Replicas (%s) found for topic %s的日志可以得知, 既然知道了原因,那么解決方案：聚焦副本為何離線了,讓副本恢復正常就行了 不過這里我們還有再重點說一下第3種情況 -
前面2個說完了,接著說一下
topicsIneligibleForDeletion到底是什么,什么情況下才會放到這里面來呢？
Controller初始化的時候判斷條件
kafka_2.11-2.0.0沒有這個步驟
- 資料正在遷移中
判斷資料是否在遷移中是通過判斷topic的是否存在要新增或者洗掉的副本, 查詢/brokers/topics/{topicName}節點中有沒有這兩個屬性值
- topic副本所在Broker有宕機導致的副本不在線
- 副本所在的資料目錄
log.dirs存在脫機磁盤
運行中判斷條件
- 發起的
StopReplica請求回傳例外,加入不符合洗掉條件 - 洗掉的程序中,發現該Topic
有副本重分配的操作則加入不符合洗掉條件 - 洗掉的程序,有副本下線了,則加入不符合洗掉條件
- 開始執行
副本重分配的操作, 則加入不符合洗掉條件
結案
經過深入原始碼排查走訪,我們基本上確定了問題的根源
副本離線,導致的洗掉流程不能完成; 通過查詢日志,也鎖定了那些個嫌疑犯,好家伙還是團伙作案
最后的解決方案也很粗暴,找到副本不正常的那幾臺Broker, 重啟 …之后副本瘋狂同步(其他一些topic資料同步);最終topic正常洗掉了
排查手冊
為了以后出現同樣類似的問題,我總結了一下問題的排查手段,給大家指明一條思路; 快速破案
- 確保
delete.topic.enable=true;組態檔查詢 - 確保當前該topic沒有進行 「副本重分配」 , 查詢zk節點
/admin/reassign_partitions的值是否有該topic、或者 節點/brokers/topics/{topicName}節點里面的屬性adding_replicas、removing_replicas有沒有值 - 確保所有副本所屬Broker均在線
- 確保副本均在線, (Broker在線并且
log.dirs沒有脫機), 搜日志"Dead Replicas "關鍵字查詢到哪些副本例外
解放方案
根據上面的排查順序,對應不同的解決方案;
如果正在進行 「副本重分配」 那么等待分配完成就可以正常洗掉了
如果是副本不在線,那么就去解決為啥不在線,該重啟就重啟
幕后黑手
這就完了嗎？
「log.dir為什么會脫機呢?」 「脫機跟資料遷移有關系嗎?」
根據以往的問題,好像資料遷移總是會伴隨著一些洗掉上的問題
導致資料目錄脫機的原因的最終BOSS是 「副本重分配」嗎？
留下懸念, 下期再見!
從上周五開始決定送書到現在,已經送出去 「 7 」本書了, 有很多朋友說沒有搶到,為了回應大家的積極性,和感謝讀者朋友的支持，今天決定再次免費送 「 4 」本; 為此我特意自費從當當網買了 「 4 」 本 《海量資料處理與大資料技術實戰》 , 免費贈送 給大家 (側邊欄也有聯系方式)
參與方式:
- 給本文「 「一鍵三連」 支持博主
- 掃描下面二維碼后添加博主「v*x」
- 本周五我會在 「朋友圈」公布贈送方式
- 「如果條件允許,我會盡量每周五都送」
這本書,從原理到實戰，在保證高并發、高可用、高可擴展性和高可維護性的基礎上，教你從零開始構建基于海量資料處理的離線批處理平臺和在線實時計算平臺等大資料系統;
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/300356.html
標籤：其他
上一篇：5-2 學習打卡（9.10）