最近在公司做hbase的小region合并操作，其实normalize就能做得，但是split会对集群造成很大负载，我的目的是合并那些已经被TTL清空了的region，经过扫描发现，这些小region的数量非常多
合并小region以及可能会出现的问题博客：HBase Region合并分析 - 哥不是小萝莉 - 博客园
小region产生的原因
0MB size的region一般都是之前大量写入，然后不断split，但是由于有TTL限制，rowkey再也无法覆盖到这个前缀的时候，那么就会出现很多0 region，这个时候为了性能着想一般都需要做一些merge小region的操作
问题出现，初步定位
于是我兴冲冲的开始写脚本，然后应用，正当我松了一口气的时候，我发现了永久RIT告警
我想的是，不会正好是我的merge出现问题了吧？不会把不会吧，我之前就看过代码了，我的代码是合并了这个patch的，但是还是出现了永久RIT告警，我赶紧登录服务器把咱的merge脚本先停了
ps -ef | grep merge? ? && kill -9 xxx~
一套操作下来我先松了一口气，打开我的hbase console仔细看了一下，应该是没多大的问题，才2个region，hhhh我马上就assign（region上线）给你看
我首先通过master的log定位到了RIT高达4000s的2个region，我都开始流汗了，那天正好居家，我可能吃饭去了x，所以没有及时发现，我得尽快处理好，不然接下来就是告警地狱了
hbase shell assign
我赶紧打开我的hbase shell，准备assign这2个region
assign 'regionname'
然后发现，master居然无法定位到merging_new的region，直接认为其不存在？这怎么可能！这个region明明就一直在告警，你告诉我找不到？那这告警我咋办？！难道真像博客说的那样重启master嘛，目前咱们集群的master重启一次要40分钟，这个季度我也是需要改进这个，现在给我一亿个胆子我也不敢重启。
hbase hbck救命
我首先起了一个hbck，看看hbase究极大神能不能给我点提示，然而只是发现了2个RIT region
./hbase hbck? && ./hbase hbck -各种fix tableName
看来指望不上了，我一边hbck，一遍根据master的最初产生region流程，想看看到底怎么回事
ZK RIT节点排查
于是我先来到了咱们的ZK，准备看一下这个节点的情况，我们知道rit的节点再zk里面一定是存在一份状态的，但是我傻眼了，zk里面居然啥都没有，直接说node not exists，ca~
?我差点直接和自己说拜拜了，我是不是定位不到问题了呀，我的未来很惨淡了呀~之类的！但是我手上的动作却没停，ZK没有，那我还得根据regionServer的log信息来判断到底咋回事呢
failed to get znode? xxx~
Caused by: org.apache.zookeeper.KeeperException$BadVersionException: KeeperErrorCode = BadVersion for /hbase/region-in-transition/406ba8e550b762c851ec0cd14f5e257b
接下来2条log就是开始回滚了
baseZNode=/hbase Attempting to delete unassig
ned node 406ba8e550b762c851ec0cd14f5e257b in RS_ZK_REQUEST_REGION_MERGE state but node is in RS_ZK_REGION_MERGING stateregionserver.RegionMergeRequest: Successful rollback of failed merge of xxx
我心里想着，您不是都回滚成功了嘛，ZK节点也正常删除了，为啥还让我RIT呢，理论上来说这个节点删掉master应该是不会继续跟踪了才对，因为ZK之中已经没有了这个节点，继续视为RIT实际上是错误的
Master为何傻乎乎
master居然还在一直检测一个没有了的节点的信息，这不得挖挖看看是为啥，肯定是某个环节卡主了
master检测RIT的代码，只需要追踪master探测hbase rit的方法即可，看从哪个地方得到RIT信息
首先是ClusterStatusChore 中的chore获取集群当前状态，包括backupmaster，以及region信息
/**
* Status information on the HBase cluster.
* <p>
* <tt>ClusterStatus</tt> provides clients with information such as:
* <ul>
* <li>The count and names of region servers in the cluster.</li>
* <li>The count and names of dead region servers in the cluster.</li>
* <li>The name of the active master for the cluster.</li>
* <li>The name(s) of the backup master(s) for the cluster, if they exist.</li>
* <li>The average cluster load.</li>
* <li>The number of regions deployed on the cluster.</li>
* <li>The number of requests since last report.</li>
* <li>Detailed region server loading and resource usage information,
* per server and per region.</li>
* <li>Regions in transition at master</li>
* <li>The unique cluster ID</li>
* </ul>
*/
@InterfaceAudience.Public
@InterfaceStability.Evolving
public class ClusterStatus extends VersionedWritable {可以发现rit信息是通过assignmentManager（AM）中获取的，其实它也是在master初始化的时候跟着初始化
也就是它里面的rit信息也是动态抓取的？那难道不是从zk抓取的吗？继续看下去
发现了RIT状态是必须进行显式更新的，而不是动态抓取，如果这个更新失败了，我都不敢想..
我觉得大概率就是因为失败了然后流程卡住了，然后zk和master还不同步，以至于zk把节点直接删了master还在傻乎乎的告警RIT
master必定还是从AM里面去拿，那么AM的信息如果一直不更新，master会持续收到相关RIT信息
AM的信息为什么不更新？啊有其他事情了，下次再慢慢分析吧
估计是信息变更的时候出了岔子，然后zk节点也删了，再也没有新的信息会发送到AM处理了，我们要做的就是点醒AM，告诉它这个region出了问题，赶紧删了完事~
解决方案
那么解决办法就是：让master知道这个region出现了问题，在发送一次信息让master帮忙解决掉这个无用region的元信息即可
既然信息在RS中无法完善，就通过重启RS的方式重新通知master相关信息，如果不重新通知可能master永远都会知道这个节点已经被zk偷偷干掉了，RS优雅重启的过程之中，会把所有的region移动出去，然后重启再移动回来，此时一定涉及到信息通知到master，master就能知道这个region有问题了
观察dead之后的方法发现如果regionServer不小心offline的话，所有的region都会被重新上线，于是我对我的肇事regionServer进行了重启打法（此时有百分之50确信自己能成）
./graceful_stop.sh -d --restart --reload --maxthreads 10 xxx节点
这里线程不要开太大，要是造成了新的RIT没地方哭了就，我特意开小了点（虽然也才600个region.. 才？）
最后定位到那个博客的方法，之前惊慌失措没有想到，其实答案确实就在这里，还好这边的节点都修复了这个bug（必须是master节点是最新代码，不然不会生效，因为是master做的这个操作）
对失败了的split和merge region，会做一个统一的清理删除工作，所以这个merging_new应该是不会诞生了~
重启之后果然RIT消失了，然后我再安心的去找到了，serverOffline会在servers dead的时候执行，这个时候会清理这些失败的region(或者说meta里面还没有记录的region信息)?
然后就会清理这些region的元信息，这个时候master就真的再也收不到它了（物理删除了）
所以最后清理会调用这个方法，这个方法可以直接在shell里面调用（甚至省去了Server重启~ 但是我没操作过哦，我只是知道可以做这样的操作，实际上也是上面那篇博客那样，找到对应的java方法，就可以直接在shell里面对hbase进行操作，其实java也可以写，但是jruby中可以访问到几乎所有的hbase类）
最后不要忘记了开启load balancer，这老哥随便做点操作就会直接歇菜，因为其他操作更加优先嘛~
总结
1.该方案只适合应用了博客中的patch才能有效根治merging_new，如果没有应用patch，又不想停止服务，可以自己通过ruby脚本调用deleteRegion来实现相同的操作「本质上重启还是走了这个方法，如果你直接调用甚至都不需要重启RS」（脚本实际上可以直接在hbase shell里面调试，hbase shell就是一个ruby shell，记住首先要测一下~）
2.遇见问题不要慌张，一边想解决方案一边实施，也许答案已经在之前看过的文章中了，不过一般线上出问题谁不慌呢？~
?
