HBase RIT~merging_new相关

最近在公司做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 state

regionserver.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.遇见问题不要慌张，一边想解决方案一边实施，也许答案已经在之前看过的文章中了，不过一般线上出问题谁不慌呢？~