REGION IN TRANSITION问题

Hbase Region in transition (RIT) 异常解决：
https://datamining.blog.csdn.net/article/details/83012500
表删除后，执行assgin 会提示超时，表的Region不存在无法执行 该命令

Hbase 2.x 版本 RIT信息已经不再Zookeeper中保存
AssignmentManagerV2：https://yq.aliyun.com/articles/601096


1、首先我们删除 hbase:meta 中的region元信息，该表已经不再在了，元信息也是没有用的垃圾数据。

上图框中的内容就是存在 meta表中的rowkey，我们直接去删除就可以

2、删除meta表数据


删除meta表数据

hbase(main):001:0> deleteall ‘hbase:meta’,‘KYLIN_HWXQTTYU05,1568778674387.ba6a12829e066958226754e5d76791e2.’
Took 0.7435 seconds
hbase(main):002:0> deleteall ‘hbase:meta’,‘KYLIN_CNJJRE3KX1,1567394580077.eb35470f15e4bb228262a54169d92c63.’
Took 0.0232 seconds5

3、停止Hbase服务
4、删除/hbase/MasterProcWALs 下的文件，
不删除该文件，master重启后还是会读取该日志文件，删除前请先备份
hdfs dfs -rm /hbase/MasterProcWALs/pv2-00000000000000000001.log
（也可能是hdfs问题，需要根据hbase日志判断，如有可根据文档下面案例分析）
5重启Hbase
发现已经没有RIT问题了，并且Hbase上出问题的相关表也消失了。

6、进入hbase sehll平衡节点
hbase(main):004:0> balancer
true
Took 159.5604 seconds

案例:HDFS文件异常
现象：线上集群很多RegionServer短时间内频频宕机，有几个Region处于FAILED_OPEN状态

分析诊断：
（1）查看系统监控以及RegionServer日志，确认RegionServer频繁宕机是因为大量CLOSE_WAIT状态的短连接导致。监控显示短时间内（4h）CLOSE_WAIT的数量从0增长到6w+。
（2）再查看RegionServer日志查看到如下日志：
2016-07-27 09:42:14,932 [RS_OPEN_REGION-inspur250.photo.163.org,60020,1469581282053-0] ERROR org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler - Failed open of region=news_user_actions,|u:cfcd208495d565ef66e7dff9f98764da
|1462799167|30671473410714402,1469522128310.3b3ae24c65fc5094bc2acfebaa7a56de., starting to roll back the global memstore size.
java.io.IOException: java.io.IOException: java.io.FileNotFoundException: File does not exist: /hbase/news_user_actions/b7b3faab86527b88a92f2a248a54d3dc/meta/0f47cda55fa44cf9aa2599079894aed6
2016-07-27 09:42:14,934 [RS_OPEN_REGION-inspur250.photo.163.org,60020,1469581282053-0] INFO org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler - Opening of region {NAME => ‘news_user_actions,|u:cfcd208495d565ef66e7dff9f9
8764da|1462799167|30671473410714402,1469522128310.3b3ae24c65fc5094bc2acfebaa7a56de.’, STARTKEY => ‘|u:cfcd208495d565ef66e7dff9f98764da|1462799167|30671473410714402’, ENDKEY => ‘|u:d0’, ENCODED => 3b3ae24c65fc5094bc2acfebaa7a56de,} faile
d, marking as FAILED_OPEN in ZK
日志显示，Region ‘3b3ae24c65fc5094bc2acfebaa7a56de’打开失败，因此状态被设置为FAILED_OPEN，原因初步认为是FileNotFoundException导致，找不到的文件是Region ‘b7b3faab86527b88a92f2a248a54d3dc’ 下的一个文件，这两者之间有什么联系呢？
（3）使用hbck检查了一把，得到如下错误信息：
（4）ERROR: Found lingering reference file hdfs://mycluster/hbase/news_user_actions/3b3ae24c65fc5094bc2acfebaa7a56de/meta/0f47cda55fa44cf9aa2599079894aed6.b7b3faab86527b88a92f2a248a54d3dc
看到这里就一下恍然大悟，从引用文件可以看出来，Region ‘3b3ae24c65fc5094bc2acfebaa7a56de’是‘ b7b3faab86527b88a92f2a248a54d3dc’的子Region，熟悉Split过程的童鞋就会知道，父Region分裂成两个子Region其实并没有涉及到数据文件的分裂，而是会在子Region的HDFS目录下生成一个指向父Region目录的引用文件，直到子Region执行Compaction操作才会将父Region的文件合并过来。
到这里，就可以理解为什么子Region会长时间处于FAILED_OPEN状态：因为子Region引用了父Region的文件，然而父Region的文件因为未知原因丢失了，所以子Region在打开的时候因为找不到引用文件因而会失败。而这种异常并不能通过简单的重试可以解决，所以会长时间掉入RIT状态。
（4）现在基本可以通过RegionServer日志和hbck日志确定Region处于FAILED_OPEN的原因是因为子Region所引用的父Region的文件丢失导致。那为什么会出现CLOSE_WAIT数量暴涨的问题呢？经确认是因为Region在打开的时候会读取Region对应HDFS相关文件，但因为引用文件丢失所以读取失败，读取失败之后系统会不断重试，每次重试都会同datanode建立短连接，这些短连接因为hbase的bug一直得不到合理处理就会引起CLOSEE_WAIT数量暴涨。
解决方案：删掉HDFS上所有检查出来的引用文件即可
1.    通过hbase hbck确认该问题；
2.    输入hbase shell，然后通过get命令找出该region在表hbase：meta中的信息：
3.    使用delete命令将该row从表hbase：meta中删除；
4.    使用hbase hbck –repair修复hbase。
5进入hbase sehll平衡节点
hbase(main):004:0> balancer