摘要： 使用過開源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. 用戶再自己驗證一下是否正常

通知用戶驗證集群運行，業務運行情況。

原文鏈接

干貨好文，請關注掃描以下二維碼：

總結

以上是生活随笔為你收集整理的云HBase小组成功抢救某公司自建HBase集群，挽救30+T数据的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。