一、背景

相信做過HBase開發(fā)、運(yùn)維相關(guān)工作的朋友多多少少都有這樣感受，HBase作為分布式非關(guān)系型數(shù)據(jù)庫中的佼佼者不僅穩(wěn)定、性能高、安裝擴(kuò)容等運(yùn)維也非常簡單，但是HBase缺乏成熟監(jiān)控系統(tǒng)對故障排查極不友好。如果缺乏對HBase全面了解在應(yīng)對日常故障經(jīng)常束手無策，小編們作為運(yùn)維大大小小20+個(gè)HBase集群涉及1.x~2.x等版本，經(jīng)歷過meta表損壞無法正常上線、Region重疊、Region空洞、權(quán)限丟失等線上問題毒打，也帶著各種各樣問題從HBase源碼中尋求正確答案，本文是小編們多次故障中總結(jié)出的meta表常見解決方案。

二、HBase meta 元信息表

HBase meta表又稱為catalog表是一張?zhí)厥獾腍Base表，它存儲(chǔ)了HBase集群所有Region和其對應(yīng)的RegionServer信息，元信息表的數(shù)據(jù)正確性對于HBase集群的正常運(yùn)行至關(guān)重要，因此需要保證元信息表的數(shù)據(jù)正確是集群穩(wěn)定運(yùn)行的必要條件。如果meta表出現(xiàn)數(shù)據(jù)不一致將會(huì)導(dǎo)致RIT（Region In Transition）甚至出現(xiàn)由于HMaster 無法正常初始化導(dǎo)致集群無法正常啟動(dòng)，由此可見meta表在HBase集群中重要性，下面我們圍繞meta表結(jié)構(gòu)、數(shù)據(jù)格式、啟動(dòng)流程進(jìn)行解析它（本文主要圍繞HBase 2.4.8版本，也會(huì)穿插HBase 1.x版本）。

2.1 meta 表結(jié)構(gòu)

meta表主要包括info、table、rep_barrier三個(gè)列族分別記錄Region信息、表狀態(tài)：

2.2 meta 表加載流程

通過上述meta表結(jié)構(gòu)我們對該表有一個(gè)整體認(rèn)識，做過HBase運(yùn)維的朋友相信都有這種經(jīng)驗(yàn)有一些集群啟動(dòng)比較快、有一些集群啟動(dòng)比較慢，甚至有時(shí)候由于操作不當(dāng)集群重啟時(shí)候一直卡在meta表加載無法繼續(xù)執(zhí)行后續(xù)流程。如果我們對meta表加載流程有一個(gè)整體了解之后我們將對每一個(gè)集群啟動(dòng)時(shí)間多多少少都有一個(gè)心理預(yù)期，以下是meta表加載相關(guān)流程：

通過以上meta表加載流程圖我們很好找到為什么有一些集群啟動(dòng)比較慢、有一些集群啟動(dòng)失敗原因了，下面我們針對兩類場景進(jìn)行分析：

集群啟動(dòng)慢：

通常新集群或者表數(shù)量比較少集群往往啟動(dòng)速度比較快，表數(shù)量比較多的集群往往啟動(dòng)相對慢很多，甚至有一些集群啟動(dòng)HMaster需要15~30分鐘，有時(shí)候集群啟動(dòng)時(shí)間比較長讓人不免懷疑是不是集群出現(xiàn)問題了，為什么那么長時(shí)間無法進(jìn)入正常狀態(tài)呢？在整個(gè)加載流程中出現(xiàn)兩個(gè)耗時(shí)比較長地方。

預(yù)加載所有表描述符：需要把HBase數(shù)據(jù)目錄全部掃描一遍并解析出.tabledesc目錄下面數(shù)據(jù)文件存放HMaster 內(nèi)存中，如果表數(shù)量比較多（超過10000張表）這一過程往往需要十來分鐘，如果我們看HMaster 頁面出現(xiàn)“Pre-loading table descriptors”字樣時(shí)說明該集群處于預(yù)加載階段我們只需耐心等待即可，因?yàn)檫€沒有到meta表加載階段。

上線業(yè)務(wù)表Region：meta表數(shù)據(jù)大小通常在幾十M到幾百M(fèi)之間Region打開時(shí)間比較快（秒級），集群啟動(dòng)階段需要檢查并上線Offline Region，如果想加快打開速度可以適當(dāng)調(diào)整hbase.master.executor.openregion.threads（默認(rèn)值為5）值。

集群啟動(dòng)失?。?/strong>

meta表上線失敗：當(dāng)default資源組的HRegionServer掛掉之后，重啟后機(jī)器的startcode變化之后，meta的數(shù)據(jù)分片找不到打開節(jié)點(diǎn)，導(dǎo)致集群啟動(dòng)失敗。

三、如何修復(fù) meta 表

由于HBase集群狀態(tài)主要是通過meta表去維護(hù)，如果meta表出現(xiàn)了損壞或錯(cuò)誤，將會(huì)導(dǎo)致HBase集群的不可用和面臨數(shù)據(jù)丟失風(fēng)險(xiǎn)。我們知道m(xù)eta表數(shù)據(jù)一致性非常重要那么什么情況會(huì)出現(xiàn)數(shù)據(jù)不一致呢？（HBase 2.4.8修復(fù)命令參考hbase-operator-tools工具）。

• RegionServer宕機(jī)或異常：當(dāng)RegionServer宕機(jī)或異常時(shí)，meta表中存儲(chǔ)的Region和RegionServer信息可能會(huì)出現(xiàn)錯(cuò)誤或丟失。
• 數(shù)據(jù)損壞或錯(cuò)誤：當(dāng)meta表中的數(shù)據(jù)損壞或錯(cuò)誤時(shí)，可能會(huì)導(dǎo)致HBase集群的不可用和數(shù)據(jù)丟失。
• 非法操作：當(dāng)對meta表進(jìn)行非法操作時(shí)，例如刪除或修改meta表中的數(shù)據(jù)，可能會(huì)導(dǎo)致meta表出現(xiàn)錯(cuò)誤或丟失。

meta表故障只是一直比較籠統(tǒng)的說法，我們可以根據(jù)類型可以大致分為長時(shí)間RIT、Region空洞、Region重疊、表描述文件丟失、meta表hdfs路徑為空、meta表數(shù)據(jù)丟失等，下面我分別對這些類型故障進(jìn)行分析并進(jìn)行修復(fù)：

3.1 RIT

RIT（Region In Transition）是指HBase集群中正在進(jìn)行狀態(tài)轉(zhuǎn)換，以下操作都會(huì)引起HBase集群中Region的狀態(tài)發(fā)生變化，例如RegionServer宕機(jī)、Region正在進(jìn)行拆分、合并等操作，Region狀態(tài)主要是包括以下十二種狀態(tài)以及轉(zhuǎn)化圖：

為了更加清晰Region狀態(tài)裝換我們根據(jù)操作類型可以分為assign、unassign、split、merge，如果操作過程出現(xiàn)RegionServer宕機(jī)或異常、數(shù)據(jù)損壞或錯(cuò)誤都會(huì)出現(xiàn)RIT，RIT雖然是在HBase運(yùn)維中經(jīng)常遇見的問題，但是如果清楚底層邏輯將會(huì)比較容易處理RIT問題，HBase集群都具備RIT修復(fù)能力大部分情況都不需要手工介入都能正?；謴?fù)，出現(xiàn)長時(shí)間RIT才需要人工介入處理，那什么是長時(shí)間RIT？為什么會(huì)出現(xiàn)長時(shí)間RIT呢？

如果用過HBase 1.x和HBase 2.x版本明顯感覺HBase 2.x比較少出現(xiàn)RIT，其實(shí)Region的操作主要是通過AssignmentManager類進(jìn)行Region轉(zhuǎn)移，對比兩個(gè)版本代碼我們發(fā)現(xiàn)hbase.assignment.maximum.attempts參數(shù)（assign重試次數(shù)）在兩個(gè)版本的默認(rèn)值不一樣，HBase 2.4.8重試次數(shù)為最大整數(shù)Integer.MAX_VALUE（而HBase 1.x中該值默認(rèn)為10），這就是為什么在HBase 2.x中比較少出現(xiàn)長時(shí)間RIT原因。

RIT處理方法：

1. 建刪大表都會(huì)出現(xiàn)RIT主要是由于Region數(shù)量比較多集群壓力比較大導(dǎo)致assign、unassign響應(yīng)時(shí)間過長導(dǎo)致，針對這類問題一般不需要人工介入HBase可以自愈。
2. 如果集群版本為1.x可以適當(dāng)調(diào)整hbase.assignment.maximum.attempts值增加重試次數(shù)，如FAILED_OPEN、FAILED_CLOSE通常都可以自愈，或者手工執(zhí)行assign命令一個(gè)個(gè)Region分配上線（如果Region比較多切換HMaster 修復(fù)）。
3. 如果出現(xiàn)Region分配失敗，不存在RegionServer時(shí)候，手工assign都沒辦法恢復(fù)，如Region被分配到bogus.example.com,1,1節(jié)點(diǎn)只能通過切換HMaster 恢復(fù)。

問題思考：

為什么Region手工介入都不能正常上線切換HMaster 就能恢復(fù)呢？（參考HMaster 啟動(dòng)流程TransitRegionStateProcedure、HMaster 類源碼）

3.2 Region 空洞

我們創(chuàng)建HBase表時(shí)如果細(xì)心去分析Region規(guī)律會(huì)奇怪發(fā)現(xiàn)Region startkey和endkey屬于左閉右開的連續(xù)區(qū)間，如果突然這些區(qū)間少了一塊（如下圖）將會(huì)出現(xiàn)什么問題呢？

出現(xiàn)上面情況就是我們常說的Region出現(xiàn)空洞，如果用HBase hbck工具檢查會(huì)看到這樣錯(cuò)誤信息ERROR: There is a hole in the region chain between 01 and 02.  You need to create a new .regioninfo and region dir in hdfs to plug the hole，HBase集群出現(xiàn)空洞往往是沒辦法自愈需要人工干預(yù)才能恢復(fù)正常，既然我們知道少了一個(gè)Region我們?nèi)绻芽瞻讌^(qū)間的Region補(bǔ)回去不就可以了嗎？正常做法是先把空白的Region補(bǔ)充回去，并檢查meta表信息是否正確，最后再上線Region，如果這一系列操作都通過手工去實(shí)現(xiàn)不僅僅容易出錯(cuò)操作時(shí)間也很長，下面分別介紹一下不同版本HBase修復(fù)方法，其實(shí)不同版本處理方法雖然有一點(diǎn)差異但是處理流程都一樣。

Region空洞處理方法：

（1）HBase 1.x修復(fù)方法  

1. HBase hbck –fixHdfsHoles：在hdfs上創(chuàng)建空Region文件路徑
2. HBase hbck -fixMeta：修復(fù)該Region所在meta表數(shù)據(jù)
3. HBase hbck –fixAssignments：上線修復(fù)之后Region
4. 或者HBase hbck –repairHoles相當(dāng)于（fixHdfsHoles、fixMeta、fixAssignments）幾個(gè)組合起來

（2）HBase 2.4.8修復(fù)方法(參考后面hbase-operator-tools工具)

由于HBase 2.4.8沒有提供相關(guān)的命令去添加Region目錄操作方面相對麻煩一點(diǎn)，其實(shí)HBase 2.4.8里面很多工具類都提供創(chuàng)建Region方法，hbase-server-2.4.8-test包中HBaseTestingUtility類都提供了操作Region相關(guān)的入口，下面我們的解決方法主要是圍繞該方法進(jìn)行恢復(fù)。

1. extraRegionsInMeta -fix：首先把meta表中hdfs目錄不存在記錄先刪除
2. HBaseTestingUtility.createLocalHRegion：創(chuàng)建hdfs文件路徑保證Region連續(xù)性
3. addFsRegionsMissingInMeta：再往meta表添加新建Region信息（添加成功之后會(huì)返還Region id
4. assigns：最后把新加入Region上線

3.3 Region 重疊

既然Region會(huì)出現(xiàn)空洞那么會(huì)不會(huì)存在這種情況，相同的startkey、endkey出現(xiàn)多個(gè)呢？答案是肯定的如果多個(gè)Region startkey、endkey是一樣的Region，那么我們將這種情況稱作Region重疊。Region重疊在HBase中比較難模擬同時(shí)也是比較難處理的一種問題。如果我們做hbck檢查時(shí)候出現(xiàn)這種日志ERROR: Multiple regions have the same startkey: 02

另外一種重疊Region跟相鄰的分片其中一個(gè)或兩個(gè)的rowkey范圍有交集，這類問題統(tǒng)稱overlap問題，針對這個(gè)比較難的場景我們通過自研工具模擬overlap問題復(fù)現(xiàn)并一鍵修復(fù)overlap(折疊)和hole(空洞)問題。

overlap問題模擬功能

Region重疊問題實(shí)際就是兩個(gè)不同Region，rowkey的范圍有交集，比如Region01的startkey和endkey是（01,03），同時(shí)另外一個(gè)Region02的范圍是（01,02），這樣兩個(gè)Region出現(xiàn)了交集（01,02），hbck檢測就會(huì)報(bào)overlap問題。

重疊問題在生產(chǎn)環(huán)境只有在Region分裂和機(jī)器同時(shí)掛掉情況下，才會(huì)出現(xiàn)overlap問題，出現(xiàn)條件比較苛刻，復(fù)現(xiàn)問題比較困難，能夠復(fù)現(xiàn)問題對后續(xù)修復(fù)和故障演練都很重要，overlap問題復(fù)現(xiàn)原理：

overlap 問題復(fù)現(xiàn)

1）生成一個(gè)rowkey范圍重疊的Region分片：

java -jar -Drepair.tableName=migrate:test_hole2 -Dfix.operator=createRegion -DRegion.startkey=06 -DRegion.endkey=07   hbase-meta-tool-0.0.1.jar

2） 將overlap問題Region移動(dòng)到表目錄下：

sudo -uhdfs hdfs dfs -mv /tmp/.tmp/data/migrate/test_hole2/c8662e08f6ae705237e390029161f58f /hbase/data/migrate/test_hole2

3） 刪除正常的表migrate:test_hole2的meta表信息：

java -jar -Drepair.tableName=migrate:test_hole2 -Dfix.operator=delete  hbase-meta-tool-0.0.1.jar

4）重構(gòu)overlap問題表元數(shù)據(jù)信息：

java -jar -Drepair.tableName=migrate:test_hole2 -Dfix.operator=fixFromHdfs  hbase-meta-tool-0.0.1.jar

5） 重啟集群后hbck報(bào)告Region重疊c8662e08f6ae705237e390029161f58f，成功復(fù)現(xiàn)重疊問題

方法一：一鍵修復(fù)overlap(重疊)和hole(空洞)

適用于折疊數(shù)量不超過64個(gè)情況下，利用自研工具 hbase-meta-tool可以將相鄰Region有rowkey交集的范圍合并，有空洞缺失范圍生成新的Region，這樣就能修復(fù)問題，問題修復(fù)原理如圖：

1）修復(fù)集群的重疊與空洞問題：

java -jar  -Dfix.operator= fixOverlapAndHole hbase-meta-tool-0.0.1.jar

方法二：大規(guī)模折疊修復(fù)

適用大規(guī)模折疊超過幾千個(gè)或者上萬個(gè)情況修復(fù)服務(wù)器端報(bào)異常，采取一下修復(fù)手段

1）一鍵清除有折疊問題表的元數(shù)據(jù)：

java -jar -Drepair.tableName=migrate:test1 -Dzookeeper.address=zkAddress -Dfix.operator=delete     hbase-meta-tool-0.0.1.jar

2）備份原始表數(shù)據(jù)：

hdfs dfs -mv /hbase/data/migrate/test/ /back

3）刪除原始表和導(dǎo)入備份數(shù)據(jù)每個(gè)Region分片：

hbase org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles /back/test/region01-regionN  migrate:test1

3.4 meta 表數(shù)據(jù)修復(fù)

HBase線上集群我們可能會(huì)遇到下面棘手問題：

• coprocessor配置錯(cuò)誤的表,找不到協(xié)處理器路徑，加載Region過程中找不到j(luò)ar，導(dǎo)致集群反復(fù)掛掉，drop命令也刪除不掉；
• HBase meta表元數(shù)錯(cuò)誤，startcode不對，上線過程中找不到服務(wù)器的表,表始終不能上線。

我們要在保證不影響集群其他表服務(wù)的情況下，單獨(dú)不停服修復(fù)問題表。

問題表的meta數(shù)據(jù)修復(fù)

1）假設(shè)表migrate:test1有問題，可以一鍵刪除問題表元數(shù)據(jù)：

java -jar -Drepair.tableName=migrate:test1 -Dfix.operator=delete  hbase-meta-tool-0.0.1.jar

2）讀取hdfs表的.regioninfo文件夾內(nèi)容，一鍵重構(gòu)正確的元數(shù)據(jù)：

java -jar -Drepair.tableName=migrate:test1 -Dfix.operator=fixFromHdfs  hbase-meta-tool-0.0.1.jar

3.5 meta 損壞

上述5種情況都是在meta表正常上線的前提下面修復(fù)，如果meta表數(shù)據(jù)損壞無法上線我們應(yīng)該怎么修復(fù)呢？通常我們都會(huì)想到重建meta表再把Region信息寫入meta表，如果集群處于下線狀態(tài)HBase shell或者HBase api通常是無法執(zhí)行create建表。

我們分析meta表初始化類InitMetaProcedure發(fā)現(xiàn)meta表創(chuàng)建流程大致分兩步走：

1）創(chuàng)建Region目錄已經(jīng).tabledesc文件

 2）分配Region并上線。

InitMetaProcedure核心源碼：

InitMetaProcedure

protected Flow executeFromState(MasterProcedureEnv env, InitMetaState state) throws ProcedureSuspendedException, ProcedureYieldException, InterruptedException {
    try {
      switch (state) {
        case INIT_META_WRITE_FS_LAYOUT:
          Configuration conf = env.getMasterConfiguration();
          Path rootDir = CommonFSUtils.getRootDir(conf);
          TableDescriptor td = writeFsLayout(rootDir, conf);
          env.getMasterServices().getTableDescriptors().update(td, true);
          setNextState(InitMetaState.INIT_META_ASSIGN_META);
          return Flow.HAS_MORE_STATE;
        case INIT_META_ASSIGN_META:
          addChildProcedure(env.getAssignmentManager().createAssignProcedures(Arrays.asList(RegionInfoBuilder.FIRST_META_RegionINFO)));
          return Flow.NO_MORE_STATE;
        default:
          throw new UnsupportedOperationException("unhandled state=" + state);
      }
    } catch (IOException e) {
}
private static TableDescriptor writeFsLayout(Path rootDir, Configuration conf) throws IOException {
    LOG.info("BOOTSTRAP: creating hbase:meta region");
    FileSystem fs = rootDir.getFileSystem(conf);
    Path tableDir = CommonFSUtils.getTableDir(rootDir, TableName.META_TABLE_NAME);
    if (fs.exists(tableDir) && !fs.delete(tableDir, true)) {
      LOG.warn("Can not delete partial created meta table, continue...");
    }
    TableDescriptor metaDescriptor = FSTableDescriptors.tryUpdateAndGetMetaTableDescriptor(conf, fs, rootDir);
    HRegion.createHRegion(RegionInfoBuilder.FIRST_META_RegionINFO, rootDir, conf, metaDescriptor, null).close();
    return metaDescriptor;
}

我們可以參照InitMetaProcedure代碼邏輯編寫相應(yīng)工具進(jìn)行建表上線操作，meta表上線之后我們只需要把每張表Region信息寫入meta并對所有Region進(jìn)行assign上線即可恢復(fù)集群正常狀態(tài)。通過以上流程我們發(fā)現(xiàn)meta表修復(fù)流程也并非那么復(fù)雜，但是如果生產(chǎn)環(huán)境表數(shù)量比較多或者個(gè)別大表Region數(shù)成千上萬那么手工添加就變的非常耗時(shí)，我們下面介紹一直相對比較簡單的解決方法（HBase 1.x hbck工具、HBase 2.x hbase-operator-tools），下面我們看一下離線修復(fù)處理流程。

HBase 1.x修復(fù)方法 

• 停止HBase集群
• sudo -u hbase hbase org.apache.hadoop.hbase.
  util.hbck.OfflineMetaRepair -fix
• 重啟集群完成修復(fù)。

HBase 2.4.8修復(fù)方法(hbase-operator-tools工具)

1）根據(jù)hdfs路徑自動(dòng)生成meta表

• 停止HBase集群
• sudo -u hbase hbase org.apache.hbase.
  hbck1.OfflineMetaRepair -fix
• 重啟集群完成修復(fù)。

2）單表修復(fù)方法

• 刪除zookeeper中HBase根目錄
• 刪除HMaster 、RegionServer所在hdfs WALs目錄
• 重啟集群此時(shí)meta沒有數(shù)據(jù)，集群無法進(jìn)入正常狀態(tài)
• 執(zhí)行添加Region命令把hbase:namespace、hbase:quota、hbase:rsgroup、hbase:acl四字表添加到集群，添加完成之后日志將會(huì)打印assigns后面跟隨這幾張表的Region，需要記錄下這些Region以便下一步assign操作。

sudo -u hbase hbase --config /etc/hbase/conf hbck -j hbase-tools.jar addFsRegionsMissingInMeta hbase:namespace hbase:quota hbase:rsgroup hbase:acl

• 把上一步添加打印Region上線

sudo -u hbase hbase --config /etc/hbase/conf hbck -j  hbase-hbck2.jar assigns regionid

• 業(yè)務(wù)表上線（只需要重復(fù)4-5步驟把業(yè)務(wù)表逐步上線）

注意事項(xiàng)

（如果業(yè)務(wù)表Region比較多第5不assign不能把Region全部上線成功，需要把表現(xiàn)disable再enable就可以正常上線）

備注：hbase-operator-tools OfflineMetaRepair工具存在以下幾個(gè)bug需要修復(fù)。

1、HBaseFsck createNewMeta方法創(chuàng)建meta表缺少.tabledesc文件

修改前：

TableDescriptor td = new FSTableDescriptors(getConf()).get(TableName.META_TABLE_NAME);

修改后：

FileSystem fs = rootdir.getFileSystem(conf);
TableDescriptor metaDescriptor = FSTableDescriptors.tryUpdateAndGetMetaTableDescriptor(getConf(), fs, rootdir);

2、HBaseFsck generatePuts默認(rèn)Region狀態(tài)為CLOSED因?yàn)镠Master 重啟時(shí)候只上線OFFLINE狀態(tài)Region（如果為CLOSED需要手工一個(gè)個(gè)Region上線工作量非常龐大）

修改前：

addRegionStateToPut(p, org.apache.hadoop.hbase.master.RegionState.State.CLOSED);

修改后：

addRegionStateToPut(p, org.apache.hadoop.hbase.master.RegionState.State.OFFLINE);

缺點(diǎn)

1）離線修復(fù)需要停止集群服務(wù)，停止時(shí)長根據(jù)修復(fù)時(shí)間而定（大概在10-15分鐘左右）。

2）如果其中存在Region重疊、空洞等問題需要手工處理完成再執(zhí)行OfflineMetaRepair離線修復(fù)命令。

四、hbase-operator-tools工具

hbase-operator-tools是HBase中的一組工具，用于協(xié)助HBase管理員管理和維護(hù)HBase集群。hbase-operator-tools提供了一系列工具，包括備份和恢復(fù)工具、Region管理工具、數(shù)據(jù)壓縮和移動(dòng)工具等，可以幫助管理員更好地管理HBase集群，提高集群的穩(wěn)定性和可靠性。需要編譯源碼之后才可以使用，源碼git地址。常見命令如下：

五、總結(jié)

HBase meta表的數(shù)據(jù)正確性對于HBase集群的正常運(yùn)行至關(guān)重要，如何保證meta表數(shù)據(jù)正確以及數(shù)據(jù)損壞之后快速修復(fù)變的極為重要，如果對meta沒有全面認(rèn)識每次集群出現(xiàn)故障將會(huì)措手無策。本文主要是圍繞meta表結(jié)構(gòu)加載流程、常見問題以及相關(guān)的修復(fù)方法分析，針對以上修復(fù)方法我們可以粗略分為以下兩大類：

• 在線修復(fù)：meta表可以正常通過hbck、自研工具進(jìn)行meta表數(shù)據(jù)修復(fù)保證數(shù)據(jù)完整性。
• 離線修復(fù)：meta表無法正常上線根據(jù)hdfs中Region信息重構(gòu)meta表恢復(fù)HBase服務(wù)。

如果集群規(guī)模比較大離線修復(fù)時(shí)間比較長集群需要長時(shí)間停止服務(wù)，大部分情況業(yè)務(wù)是不能容忍可以結(jié)合實(shí)際情況進(jìn)行表級別修復(fù)（除非meta表文件損壞不能正常上線），建議定時(shí)對集群做hbck檢查一旦出現(xiàn)元信息不一致情況盡快修復(fù)避免問題擴(kuò)散（如元信已經(jīng)錯(cuò)亂做集群重啟錯(cuò)亂Region將會(huì)由于assign失敗導(dǎo)致其他Region無法正常上線），如果定時(shí)巡檢發(fā)現(xiàn)有業(yè)務(wù)表出現(xiàn)元信息錯(cuò)亂情況直接重meta表把該表信息刪除并根據(jù)根據(jù)hdfs路徑信息重新把Region加回meta表（addFsRegions-

MissingInMeta命令可以根據(jù)hdfs路徑把Region正確添加到meta表）。

參考文章：

• Apache HBase ? Reference Guide
• Apache HBase HBCK2 Tool
• Appendix C: hbck In Depth