HBase的RS关闭过程和Region重分配（二）

上一篇blog谈到了rs挂掉的几种情况。

 

HBase作为nosql的一种产品，应用于大规模分布式的海量数据，其中有一个优点就是其对于机器down掉的容错性。

客户端不需要关注机器是否挂掉或者怎么样，server会自动处理down的server，处理器上的region并分配到其他server从而最大限度地提高系统可用性

 

今天来看看当rs挂掉以后的处理情况。

 

前面我们说过rs启动以后会在zk上的rs目录下注册自己的节点，而master监听了这一节点的变化包括delete，changed，created等动作。此时master监听到了node deleted事件会按如下处理：

    this.deadservers.add(serverName);
    this.onlineServers.remove(serverName);
    this.serverConnections.remove(serverName);    CatalogTracker ct = this.master.getCatalogTracker();
    // Was this server carrying root?
    boolean carryingRoot;
    try {
      HServerAddress address = ct.getRootLocation();
      carryingRoot = address != null &&
        hsi.getServerAddress().equals(address);
    } catch (InterruptedException e) {
      Thread.currentThread().interrupt();
      LOG.info("Interrupted");
      return;
    }
     HServerAddress address = ct.getMetaLocation();
    boolean carryingMeta =
      address != null && hsi.getServerAddress().equals(address);
    if (carryingRoot || carryingMeta) {
      this.services.getExecutorService().submit(new MetaServerShutdownHandler(this.master,
        this.services, this.deadservers, info, carryingRoot, carryingMeta));
    } else {
      this.services.getExecutorService().submit(new ServerShutdownHandler(this.master,
        this.services, this.deadservers, info));
    }
 

 逻辑也比较简单，从master内存中删除该rs，删除connection，判断是否有root或是meta在其上

然后起线程servershutdown来处理，servershutdown的处理如下：

首先把该rs的log split掉，按region分别放到每个region目录下的recovered.edits 目录下，一个线程读3个线程写

splitLog(serverName)

 

 清除所有到该rs的regionplan，清楚master内存上的该rs的region，找到online的处于rit队列中的该rs的region

List<RegionState> regionsInTransition =
      this.services.getAssignmentManager().processServerShutdown(this.hsi);

  若包含root或是meta则需assign

    if (isCarryingRoot()) { // -ROOT-
      try {
    	 this.services.getAssignmentManager().assignRoot();
      } catch (KeeperException e) {
        this.server.abort("In server shutdown processing, assigning root", e);
        throw new IOException("Aborting", e);
      }
    }

    // Carrying meta?
    if (isCarryingMeta())this.services.getAssignmentManager().assignMeta(); 

 等待meta表上线，扫描meta表，寻找需要重新assign的region，其中为处于RIT队列中的会重新分配，处于RIT中且状态是PENDINGCLOSE或是CLOSING的将重新assign，而RIT中的其他状态不许重新分配，因为RIT超时后会自动reassign这些region

 for (RegionState rit : regionsInTransition) {
      if (!rit.isClosing() && !rit.isPendingClose()) {
        LOG.debug("Removed " + rit.getRegion().getRegionNameAsString() +
          " from list of regions to assign because in RIT");
        hris.remove(rit.getRegion());
      }
    }
for (Map.Entry<HRegionInfo, Result> e: hris.entrySet()) {
      if (processDeadRegion(e.getKey(), e.getValue(),
          this.services.getAssignmentManager(),
          this.server.getCatalogTracker())) {
        this.services.getAssignmentManager().assign(e.getKey(), true);
      }
    }

 而在上面的挑选region assign的过程当中会存在bug

 

如一个region 从A move 到B ，其操作为close region IN A 然后 open region In B 。但是当region在B上线之前，此时由于已经关闭了region，故该region在master处是offline的，但是在meta表中还存在，而且RIT队列中也有。

如此时A server 挂掉，那么通过上述的分配规则，显然region 要assign，而此时 region 在B中上线，然后RIT队列中又存在一个对region的分配，从而造成region的二次分配，二者会对数据的一致性造成很大的影响