记一次OBJECTS元数据表处于RIT的解决办法

最近一客户环境由于Hadoop故障&＃xff0c;恢复时出现“_MD_".OBJECTS处于RIT状态&＃xff0c;且长期不能恢复。使用Trafodion用户执行HBCHECK输出如下&＃xff0c;

HBase is available!HBase version: 1.1.2.2.4.3.0-227
HMaster: namenode-2.esg.local,16000,1568772195966Number of RegionServers available:4
RegionServer #1: datanode-3.esg.local,16020,1568772200461
RegionServer #2: datanode-4.esg.local,16020,1568772200097
RegionServer #3: datanode-2.esg.local,16020,1568772200709
RegionServer #4: datanode-1.esg.local,16020,1568772201234Number of Dead RegionServers:0
Number of regions: 31014
Number of regions in transition: 1
RegionInTransition: TRAF_RSRVD_1:TRAFODION._MD_.OBJECTS,,1529534107727.e5b72fdd54857972797d8c6583964d0a. state&＃61;OPENING, ts&＃61;Tue Sep 17 22:12:38 EDT 2019 (420s ago), server&＃61;null
Average load: 7753.5


RegionInTransition: TRAF_RSRVD_1:TRAFODION._MD_.OBJECTS,1529534107727.e5b72fdd54857972797d8c6583964d0a. state&＃61;OPENING, ts&＃61;Tue Sep 17 22:12:38 EDT 2019 (420s ago), server&＃61;null 表示TRAFODION._MD_.OBJECTS处于RIT状态。

经过一番尝试与努力之后&＃xff0c;问题得以解决&＃xff0c;在此分享一下尝试过的方法&＃xff0c;仅供参考。
方法一
怀疑是HBase 自动split功能导致&＃xff0c;把split关闭。方法为&＃xff1a;修改split策略从org.apache.hadoop.hbase.regionserver.ConstantSizeRegionSplitPolicy为org.apache.hadoop.hbase.regionserver.IncreasingToUpperBoundRegionSplitPolicy&＃xff0c;将hbase.hregion.max.filesize从默认的10G调整为100G。
重启HBase&＃xff0c;验证问题仍然存在。

方法二
移除备份HBase的WAL目录&＃xff0c;
hadoop fs -mkdir /hbase-wal-bak20190918
hadoop fs -mv /apps/hbase/data/WALs/* /hbase-wal-bak20190918/
完成以上命令后重启HBase&＃xff0c;验证问题仍然存在。

方法三
手动assign表的region&＃xff0c;
hbase(main):002:0> assign ‘e5b72fdd54857972797d8c6583964d0a’
完成后验证问题仍然存在。

方法四
&＃xff08;注&＃xff1a;此步骤可能导致数据丢失&＃xff0c;生产环境慎用&＃xff09;
删除表对应的recovered.edits
hadoop fs -rmr /apps/hbase/data/data/TRAF_RSRVD_1/TRAFODION._MD_.OBJECTS/e5b72fdd54857972797d8c6583964d0a/recovered.edits
重启HBase后&＃xff0c;问题消失。

完成以上步骤后再执行hbcheck&＃xff0c;输出如下&＃xff0c;

HBase is available!HBase version: 1.1.2.2.4.3.0-227
HMaster: namenode-1.esg.local,16000,1568791177953Number of RegionServers available:4
RegionServer #1: datanode-1.esg.local,16020,1568791183192
RegionServer #2: datanode-2.esg.local,16020,1568791182670
RegionServer #3: datanode-4.esg.local,16020,1568791182598
RegionServer #4: datanode-3.esg.local,16020,1568791182581Number of Dead RegionServers:0
Number of regions: 31015
Number of regions in transition: 0
Average load: 7753.75


方法五
有时候&＃xff0c;步骤四操作完成后问题可能依然存在&＃xff0c;zookeeper下面可能还存在RIT的znode节点&＃xff0c;我们需要去zookeeper-client中把对应的RIT删除。

[zk: datanode-2.esg.local:2181,datanode-1.esg.local:2181,datanode-3.esg.local:2181(CONNECTED) 3] ls /hbase-unsecure/region-in-transition
[e5b72fdd54857972797d8c6583964d0a]
[zk: datanode-2.esg.local:2181,datanode-1.esg.local:2181,datanode-3.esg.local:2181(CONNECTED) 4] rmr /hbase-unsecure/region-in-transition


方法六
使用hbase hbck来修复RIT的问题&＃xff0c;
先命令检查命令来检查不一致的状态&＃xff0c;

hbase hbck -details TRAF_RSRVD_1:TRAFODION._MD_.OBJECTS


然后使用以下命令来修复不一致的问题&＃xff0c;

hbase hbck -fixAssignments TRAF_RSRVD_1:TRAFODION._MD_.OBJECTS


综上&＃xff0c;方法四、五、六&＃xff0c;可以解决问题的机率比较大&＃xff0c;但方法四有丢数据的风险。在生产环境&＃xff0c; 我们一般采用方法五结合方法六来处理&＃xff0c;如果未果&＃xff0c;再加上重启HBase&＃xff0c;应该可以解决大部分情况。