概述

         使用過開源HBase的人都知道，運維HBase是多麼複雜的事情，叢集大的時候，讀寫壓力大，配置稍微不合理一點，就可能會出現叢集狀態不一致的情況，糟糕一點的直接導致入庫、查詢某個業務表不可用， 甚至叢集執行不了。在早期0.9x版本的時候，HBase的修復工具還有一下bug，使得即使你懂得如何修復的情況下，依然需要多次重複執行命令，繞過那些不合理的修復邏輯，甚至有時候需要自己寫程式碼預先修復某個步驟。

背景

        上週五，某公司使用的某DataHub 大資料產品自建一個HBase叢集掛了！整個叢集有30+T 業務資料，是公司的資料中心，叢集直接啟動不了。他們也是經歷了熬戰一天一夜的情況下，但依舊沒有解決恢復，還曾有過重灌叢集重導資料念頭。最後，通過HBase技術交流群找到群主——阿里雲HBase封神。隨後其立即下達命令，臨時成立 HBase搶救小分隊，盡力最大的努力，使用最低風險的方式，搶救最完整的

    蹭蹭蹭，幾個搶救隊員集齊，開始救火。

救火開始 

        雖然緊急，但是搶救工作不能亂，我們把救火過程主要分為幾步：

1.定位現象問題所在

        首先與使用者溝通現場環境情況，以及客戶在出問題之前做過哪些重大操作，特別是一些特殊操作，平時沒做過的。據使用者描述已經遠端觀察瞭解到，使用者使用開源的某DataHub自建了一個HBase叢集， 儲存公司的大量的業務，是公司的資料中心。叢集有7個RegionServer、2個Master，32核256G的機器配置，業務資料量有30+T。HBase的master已經都掛了，兩個RegionServer也掛了，使用者使用過“重啟大法”，依舊無法正常執行。

        寥寥幾句沒有更多資訊，我們只能上叢集開日誌，打jstack，觀察HBase執行流程為什麼中斷或者掛掉。

        首先我們先檢查HDFS檔案系統，fsck發現沒有什麼異常。其次開始檢查HBase，把Debug日誌開啟，全部關閉HBase叢集，為了便於觀察現象，只啟動一個Master和一個RegionServer。啟動後，發現Master 因為fullscan meta表（master啟動的一個流程）timeout Abort 終止了。觀察meta region分配到的RegionServer也掛了，檢視日誌並沒有異常，貌似是這個開源的DataHub 當RegionServer scan資料操作超時 會被manager kill掉的樣子。打jstack發現，Master確實在等待fullscan meta完成，而接管meta region的RegionServer確實一直在忙著scan meta資料，確實有忙不過來超時了。按理說，掃描meta表應該很快的才對。

        檢查發現HDFS的HBase meta表有1T多資料！！！進一步檢視現象HFile的內容，發現了大量的Delete famly 的cell存在，而且很多是重複的，序列號（沒有截圖，想象一下）。問題現象定位了，使用者使用這個系列的DataHub 的HBase生態時，有元件存在bug往hbase meta表寫了大量的這些冗餘的delete資料，導致hbase 啟動時full scan meta卡著，最終導致整個叢集無法正常啟動執行服務。

2. 提出解決方案，評估風險

        我們很快生成了兩個相對較優的方案。第一個是使用離線compaction，把hbase meta表進行一次major compaction把多餘的delete family刪除，然後再重啟即可。第二個方案是，直接移除meta 表的無用hfile, 逆向生成meta 表資料進行修復meta表即可。

        第一個方案做離線compaction對叢集來說沒有什麼風險，缺點是離線compaction並不快，因為meta表region只有一個，執行離線meta表compaction時只有一個task，非常的緩慢耗時。

        第二個方案是逆向修復meta表資訊。看似風險很大，其實實際操作起來，很多風險可以降低。我們可以備份好核心的元資料，只有就可以在恢復失敗的時候，還原到原來修復手術的前狀態。這樣一來，這個修復過程也就風險極大降低了。

3. 開始實施

        秉著更安全風險更低的情況下，我們還是先選擇了方案一，給meta表做離線major compaction的方案。但最終因為MapReduce和本地模式的compaction都太慢了，開始會oom，調整後，最終因meta的hfile checksum校驗失敗中斷了。meta表的hfile都存在問題，那麼這個compaction過程就不能正常進行了。

        我們開始選擇方案二，和使用者溝通風險後，開始制定操作步驟， 把這個方案的實施帶來的風險儘可能降到最低。規避這個方案存在的風險，前提是懂得這個方案會有什麼風險。下面我們來分析一下，如圖：

 可以看到，開源HBase的meta表，是可以逆向生成回來的，但是有可能不同的DataHub生產商可能會有一些額外的資訊hack進meta表裡，對於這部分資訊，在開源的逆向生成過程中是不包含的，存在這個關係資料丟失。但是這些核心的業務資料都存在，只是hack的第三方關聯資訊不存在了。有人可能會問，會有哪些資料可能hack到這裡呢？曾看到過某廠商會在meta表了多加一些額外的欄位用來儲存virtual hostname資訊，還有一些將二級索引相關的資訊會儲存在tableinfo 檔案那裡。HBase的開發商越多，什麼姿勢都可能存在，這個就是可能的風險點。

        接下來我們開始實施，這個問題比較典型，使用者的meta表裡，有1T多的hfile 資料，檢查hfile 發現幾乎99%的hfile是delete famly相關的內容，我們就移除這些delete famly的hfile到備份目錄，只留下一個正常資料的hfile，而這個hfile也僅僅有30M左右的資料。重啟HBase後，正常執行。HBase一致性檢查發現很幸運，沒有壞檔案，也沒有丟失的tableinfo、regioninfo、hfile相關的block等。如果發現有檔案丟失，corrupt hfile等等問題，逆向生成元資料的修復過程就可能會帶來風險，但HBase叢集核心業務資料依然可以完整挽救。

4. 使用者再自己驗證一下是否正常

        通知使用者驗證叢集執行，業務執行情況。

小結

        由於使用者的自建HBase叢集不像雲HBase一樣可以我們遠端登入管理，只能使用一些遠端桌面工具先登入到使用者的工作PC再跳到叢集環境上，整個操作起來非常的卡頓，影響了問題定位以及最終搶救的效率。

        很多使用者使用某些開源DataHub自建叢集都會碰到各種各樣的運維問題，不要害怕，只要HDFS資料不丟失，HBase怎麼掛都可以拯救回來的，不用急著格式化HBase叢集重灌/重導資料。

歡迎大家新增本次救火的“消防員”---封神，大家有相關問題可以一起交流探討

猜你喜歡

加入技術討論群

《大資料和雲端計算技術》社群群人數已經3000+，歡迎大家加下面助手微信，拉大家進群，自由交流。

喜歡QQ群的，可以掃描下面二維碼：

歡迎大家通過二維碼打賞支援技術社群（英雄請留名，社群感謝您，打賞次數超過108+）：