概述
使用過開源HBase的人都知道，運維HBase是多麼複雜的事情，叢集大的時候，讀寫壓力大，配置稍微不合理一點，就可能會出現叢集狀态不一緻的情況，糟糕一點的直接導緻入庫、查詢某個業務表不可用， 甚至叢集運作不了。在早期0.9x版本的時候，HBase的修複工具還有一下bug，使得即使你懂得如何修複的情況下，依然需要多次重複運作指令，繞過那些不合理的修複邏輯，甚至有時候需要自己寫代碼預先修複某個步驟。
背景
上周五，某公司使用的某DataHup 大資料産品自建一個HBase叢集挂了！整個叢集有30+T 業務資料，是公司的資料中心，叢集直接啟動不了。他們也是經曆了熬戰一天一夜的情況下，依舊沒有解決恢複，還曾有過重裝叢集重導資料念頭。最後，通過釘釘HBase技術交流群找到群主——阿裡雲HBase的封神。随後其立即下達指令，臨時成立 HBase搶救小分隊，盡力最大的努力，使用最低風險的方式，搶救最完整的叢集。
蹭蹭蹭，幾個搶救隊員集齊，開始救火。
救火開始
雖然緊急，但是搶救工作不能亂，我們把救火過程主要分為幾步：
1. 定位現象問題所在
首先與使用者溝通現場環境情況，以及客戶在出問題之前做過哪些重大操作，特别是一些特殊操作，平時沒做過的。據使用者描述已經遠端觀察了解到，使用者使用開源的某DataHup自建了一個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也挂了，檢視日志并沒有異常，貌似是這個開源的DataHup 當RegionServer scan資料操作逾時 會被manager kill掉的樣子。打jstack發現，Master确實在等待fullscan meta完成，而接管meta region
的RegionServer确實一直在忙着scan meta資料，确實有忙不過來逾時了。按理說，掃描meta表應該很快的才對。
檢查發現HDFS的HBase meta表有1T多資料！！！進一步檢視現象HFile的内容，發現了大量的Delete famly 的cell存在，而且很多是重複的，序列号（沒有截圖，想象一下）。問題現象定位了，使用者使用這個系列的DataHup 的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表，是可以逆向生成回來的，但是有可能不同的DataHup生産商可能會有一些額外的資訊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再跳到叢集環境上，整個操作起來非常的卡頓，影響了問題定位以及最終搶救的效率。
很多使用者使用某些開源DataHup自建叢集都會碰到各種各樣的運維問題，不要害怕，隻要HDFS資料不丢失，HBase怎麼挂都可以拯救回來的，不用急着格式化HBase叢集重裝/重導資料。更多HBase 故障恢複技術交流，請關注釘釘HBase技術交流群。
最後播報一下，雲HBase2.0 在2018年6月6日将正式釋出，
點選了解更多