雲HBase小組成功搶救某公司自建HBase集羣，挽救30+T數據

摘要： 使用過開源HBase的人都知道，運維HBase是多麼複雜的事情，集羣大的時候，讀寫壓力大，配置稍微不合理一點，就可能會出現集羣狀態不一致的狀況，糟糕一點的直接致使入庫、查詢某個業務表不可用, 甚至集羣運行不了。

 

概述

 

 使用過開源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. 用戶再本身驗證一下是否正常

 

    通知用戶驗證集羣運行，業務運行狀況。

 

原文連接

閱讀更多幹貨好文，請關注掃描如下二維碼：