HBase運維基礎——元數據逆向修復原理

時間 2019-12-13

標籤 hbase 基礎數據逆向修復原理欄目 Hadoop 简体版

原文原文鏈接

背景
鑑於上次一篇文章——「雲HBase小組成功搶救某公司自建HBase集羣，挽救30+T數據」的讀者反饋，對HBase的逆向工程比較感興趣，並諮詢如何使用相應工具進行運維等等。總的來講，就是想更深層理解HBase運維原理，提升運維HBase生產環境的能力，應對各類常見異常現象。不一樣的讀者對hbase的瞭解程度不一樣，本文不打算着重編寫一個工具怎麼使用，而是從HBase的運維基礎知識介紹開始講解。爲了能幫助大部分讀者提升HBase運維能力，後續會寫個「HBase運維繫列」專題系列文章。html

介紹

相信不少自建HBase的企業會常常碰到各類各樣的hbase運維問題。好比使用HBase的時候，HBase寫入一段時間後開始RegionServer節點開始掛掉，重啓RegionServer發現啓動很慢，不少region出現RTI問題，致使讀寫某個region的業務hang住了。還有一些人的HBase集羣屢次運維嘗試後，直接HBase啓動不了了，meta表上線就開始報錯，致使最終業務不能正常上線運行等等系列問題。本文就HBase運維的原理基礎開始入手，重點講解數據完整性，以及元數據「逆向工程」恢復數據完整性的原理方法。開啓後續一系列的HBase運維知識講解。apache

HBase目錄結構
本文就1.x版本進行講解，不一樣版本大體相通。HBase在HDFS上會單獨使用一個目錄爲HBase文件目錄的根目錄，一般爲「/hbase」。基於這個目錄下，會有如下目錄組織結構：運維

/hbase/archive (1)
/hbase/corrupt (2) 
/hbase/data/default/TestTable/.tabledesc/.tableinfo.0000000001 (3)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/info/2e58b3e274ba4d889408b05e526d4b7b (4)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/recovered.edits/340.seqid (5)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.regioninfo (6)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.tmp (7)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.splits (8)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.merges (9)
/hbase/data/hbase/acl (10)
/hbase/data/hbase/meta (11)
/hbase/hbase.id (12)
/hbase/hbase.version (13)
/hbase/MasterProcWALs (14)
/hbase/oldWALs (15)
/hbase/.tmp (16)
/hbase/.trashtables/data (17)
/hbase/WALs/tins-donot-rm-test-hb1-004.hbase.9b78df04-b.rds.aliyuncs.com,16020,1523502350378/tins-donot-rm-test-hb1-004.hbase.9b78df04-b.rds.aliyuncs.com%2C16020%2C1523502350378.default.1524538284034 (18)

(1) 進行snapshot或者升級的時候使用到的歸檔目錄。compaction刪除hfile的時候，也會把就的hfile歸檔到這裏等。工具

(2) splitlog的corrupt目錄，以及corrupt hfile的目錄。oop

(3) 表的基本屬性信息元文件tableinfo。spa

(4) 對應表下的hfile數據文件。
(5) 當splitlog發生時，一個RS的wal會按照region級別split WALs寫到對應目錄下的的recovered.edits目錄上，使得此region再次被open的時候，回放這些recovered.edits 日誌。設計

(6) regioninfo文件。日誌

(7) compaction等的臨時tmp目錄。code

(8) split時臨時目錄，若是上次region的split沒有完成被中斷了，這個region再open的時候會自動清理這個目錄，通常不須要人工干預。orm

(9) merges時的臨時目錄，和split同樣，若是沒有正常完成的時候被中斷了，那麼他會在下次被open的時候自動清理。通常也不須要人工干預。

(10) acl 開啓HBase權限控制時的權限記錄系統表

(11) meta 元數據表，記錄region相關信息

(12) hbase.id 集羣啓動初始化的時候，建立的集羣惟一id。能夠從新fix生成
(13) hbase.version hbase 軟件版本文件，代碼靜態版本，如今都是8
(14) master執行過程程序的狀態保存，用於中斷恢復執行使用。

(15) oldWALs 歷史wal，即wal記錄的數據已經確認持久化了，那麼這些wal就會被移到這裏。splitlog完成的那些就日誌，也會被放到這裏。

(16) tmp 臨時輔助目錄，好比寫一個hbase.id文件，在這裏寫成功後，rename到 /hbase/hbase.id

(17) /hbase/.trashtables/data 當truncate table或者delete table的時候，這些數據會臨時放在這裏，默認1小時內被清

(18) 記錄着一臺RegionServer上的WAL日誌文件。能夠看到它是regionserver名字是有時間的，即下一次啓動時RS的wal目錄就會使用新的目錄結構存放wal，這個舊的RS wal 目錄就會被splitlog過程拆分回放

HBase涉及的主要文件及用途

HDFS靜態文件，HDFS上的HBase 數據完整性

hfile文件：數據文件，目前最高版本也是默認經常使用版本爲 3。 hfile文件結構細節能夠參考官網http://hbase.apache.org/book....。咱們這裏逆向生成元數據主要使用到了HFile fileinfo的firstkey、lastkey信息。
hfilelink文件: 在hbase snapshot時用到, migration upgrade 也會使用到。不多碰到這類文件的運維問題，這裏不做過多介紹。
reference文件：用來指定half hfile，一個region有reference時，這個region不能split。split/merge會建立這個。進行compaction後生成新的hfile後，會把這個reference刪除。hfile的reference文件名格式通常是 hfile.parentEncRegion。如：/hbase/data/default/table/region-one/family/hfilename。其region-two有reference hfile文件名格式爲：/hbase/data/default/table/region-two/family/hfile.region-one 一般無效引用就是 region-one的hfile不存在了，那麼這個引用就會失效。他的修復方法通常是把reference無效的引用移除。
".regioninfo" 文件，保存着 endkey/offline標誌/regionid/regionName/split標誌/startkey/tablename等
tableinfo文件這類文件保存着 tableName/table屬性信息/table級別config信息/family信息。其中family信息保存着 famliyName/famiy屬性/famliy級別config信息等。

一般，table屬性有：REGION_MEMSTORE_REPLICATION,PRIORITY,IS_ROOT_KEY等，通常這些屬性默認也是根據配置的同樣。family屬性有：BLOCKSIZE,TTL，REPLICATION_SCOPE等，通常屬性是根據配置使用默認的。

hbase:meta表數據內容格式
regionname, info:regioninfo, regioninfo的encodeValue值

regionname, info:seqnumDuringOpen, 序列號

regionname, info:server, region所在的server名

regionname, info:serverstartcode, regionserver 啓動的timestamp

元數據逆向生成原理

上述介紹的數據文件中，HBase的主要的元數據主要由meta表、tableinfo、regioninfo構成。這裏的逆向生成元數據指的是，根據數據hfile數據文件，反向生成regioninfo/tableinfo/meta表的過程。

1. 逆向生成tableinfo文件

case1. 經過從master進程內存中的tabledescritor cache 完整恢復tableinfo文件，此時恢復的tableinfo是完整的，和以前的徹底同樣。

case2. 當cache中沒有加載過此表的tableinfo時，修復過程只能從表的目錄結構list全部familyNames 來恢復tableinfo，這個時候只能獲得的是列簇的名字，恢復tableinfo文件內容中，除了表名、列簇名一致，其餘的屬性均採用默認值。這個時候若是運維人員知道有什麼屬性是自定義進去的，那麼就須要要手動再次添加進去。

2. 逆向生成regioninfo文件

hfile 中的fileinfo讀取firstkey/lastkey 排好序，獲得region下全部hfile的最大rowkey和最小rowkey，並根據tableinfo中的表名完整恢復 regioninfo文件。主要這裏只能恢復代表/startkey/endkey, 其餘屬性如：offline標誌，regionName,split標誌，hashcode等均使用代碼生成或者配置的默認值。

3. 逆向填充meta錶行

regioninfo文件序列化，填入meta表 info:regioninfo 列，並同時寫入默認的server，等它被再次open的時候，從新分配region到實際的regionserver上，並更新這裏的數據行。

逆向工程除了上面的直接文件、數據內容修復外，還涉及到數據的完整性其餘方面修復。一個表示由無窮小的rowkey到無窮大的rowkey範圍組成，還可能會發生的問題如：region空洞、region重疊現象，如：

若是有region空洞的時候，就會使用他們的空洞邊界做爲startkey/endkey，再修復建立一個region目錄及目錄下的regioninfo文件。若是是region重疊，則會把重疊的region進行合併，取全部region的最大最小rowkey做爲merge後新region的最大最小rowkey。

元數據工具修復

元數據的缺乏或者完整性有問題，會影響系統運行，甚至集羣直接不可用。最多見的如 meta表上線失敗，region 上線open失敗等。這裏介紹兩個工具，工具一: hbase hbck 在線修復完整性修復元數據信息，工具二：OfflineMetaRepair 離線重建 hbase:meta 元數據表。

在線hbck修復：
前提：HDFS fsck 確保 hbase跟目錄下文件沒有損壞丟失，若是有，則先進行corrupt block 移除。

步驟1. hbase hbck 檢查輸出因此ERROR信息，每一個ERROR都會說明錯誤信息。

步驟2. hbase hbck -fixTableOrphones 先修復tableinfo缺失問題，根據內存cache或者hdfs table 目錄結構，從新生成tableinfo文件。

步驟3. hbase hbck -fixHdfsOrphones 修復regioninfo缺失問題，根據region目錄下的hfile從新生成regioninfo文件

步驟4. hbase hbck -fixHdfsOverlaps 修復region重疊問題，merge重疊的region爲一個region目錄，並重新生成一個regioninfo

步驟5. hbase hbck -fixHdfsHoles 修復region缺失，利用缺失的rowkey範圍邊界，生成新的region目錄以及regioninfo填補這個空洞。

步驟6. hbase hbck -fixMeta 修復meta表信息，利用regioninfo信息，從新生成對應meta row填寫到meta表中，併爲其填寫默認的分配regionserver

步驟7. hbase hbck -fixAssignment 把這些offline的region觸發上線，當region開始從新open 上線的時候，會被從新分配到真實的RegionServer上 , 並更新meta表上對應的行信息。

離線OfflineMetaRepair重建：
前提：HDFS fsck 確保 hbase跟目錄下文件沒有損壞丟失，若是有，則先進行corrupt block 移除

步驟1：執行 hbase org.apache.hadoop.hbase.util.hbck.OfflineMetaRepair -fix

最後，兩個工具使用說明都比較詳細，通過上面的基礎介紹，相信都會看的懂的。這裏不對工具再細緻說明，工具的說明能夠參考官網或者工具提示。題外話，有些開源組件設計的時候，向hbase元數據文件寫入一些特有的信息，可是並無修改到hbase工具的修復工具，或者它本身沒有維護修復工具，若是這類文件損壞、丟失了，那麼相應的組件就會運行不正常。使用這類組件的用戶，應該不只記錄好你的表的基本結構，還要記錄表的屬性配置等，當發生修復運維行爲的時候，主要再次覈對確認。