HBase宕机的多种场景

 异常导致的退出会通过接口Abortable定义的abort()方法实现，Abortable实现类如下： 
 
 由以上类图可以看出HBaseAdmin的abort由于是client的访问，因此终止服务只需抛出异常即可，HConnection也是用于client，因此只需关闭连接，如果是zk的异常会在后续的使用中重新连接zk而不用关闭连接，其中重点的是HMaster、HRegionServer和ZookeeperWatcher三个子类：

 

HMaster

HMaster会出现异常(执行abort())停止的场景如下：

1.zk异常导致的master停止服务是最常见的场景，涉及操作包含但不限于以下：

  a)Zk链接超时，超时时间通过zookeeper.session.timeout配置，默认为3分钟, 如果fail.fast.expired.active.master配置的值为false（默认为false），则不会立即abort，而是会尝试恢复zk的过期session；

  b)在打开region后，需要从zk中删除opened节点，如果zk有该节点，但是删除失败；

  c)在split region过程中，从zk删除split节点时；

  d)Master节点改变时；

  e)从zk中创建unassigned节点时；

  f)在下线disabled的regoin时，从zk中删除disabled的region如果发生zk异常；

  g)还有很多操作zk的节点时如果出现异常。

2.在assign时，如果设置region为offlined状态，但是region之前的状态不是closed或者offlined；

3.在assign时，如果无法从.META.表中读取region信息；

4.把新的hbase集群加入到正在运行的hbase集群时，如果zk的/hbase/unassigned节点没有数据；

5.使用线程池批量分配region时，如果出现未被捕获的异常，实现方式如下：

 

ThreadFactoryBuilder builder = new ThreadFactoryBuilder(); builder.setUncaughtExceptionHandler(getUncaughtExceptionHandler()); Executors. newFixedThreadPool(threadCount, builder.build()); protected UncaughtExceptionHandler getUncaughtExceptionHandler() {     return new UncaughtExceptionHandler() {       public void uncaughtException(Thread t, Throwable e) {         server.abort("Uncaught exception in " + t.getName(), e);       }     };   }

6.在启动master的服务线程时，出现了异常；

7.在hdfs中检查hbase日志路径时，发现了dead的server时，需从hdfs中读出log，如果出现io异常需要检查hdfs文件系统，如果fsOk状态为true，但是通过FSUtils工具类进行检查时出现io异常；

8.在校验并且分配-ROOT-的region时，如果zk异常，或者其它异常（其它异常会重试10次），比如：“-ROOT- is onlined on the dead server”。 

 

HRegionServer

HRegionServer会出现异常停止(执行abort())服务的场景如下：

1.在读写hdfs时如果出现IOException异常，此时会发起hdfs的文件系统检查（checkFileSystem）1.          

public boolean checkFileSystem() {     if ( this.fsOk && this.fs != null) {       try {         FSUtils. checkFileSystemAvailable( this.fs);       } catch (IOException e) {         abort("File System not available", e);         this.fsOk = false;       }     }     return this.fsOk;         }

2.Regionserver的服务线程出现了未捕获异常；

3.在启动HRegionServer时出现异常；

4.在进行HLog回滚时，出现异常；

5.在flush memstore时，如果持久化失败，会重启RS，在重启中把hlog的内容重新加载到memstore；

6.出现zk异常，包括但不限于以下场景：

  a)Zk链接超时，超时时间通过zookeeper.session.timeout配置，默认为3分钟，与master不同，如果zk操作不会重试；

  b)启动HRegionServer时出现KeeperException异常； 

  c)在进行split操作时，如果出现异常会进行回滚操作，在回滚过程中需要从zk中删除region的spliting状态，如果删除时出现KeeperException或者回滚的其它操作出现异常；

  d)在打开region时，出现了KeeperException异常；

  e)在进行hbase集群复制时，很多与zk交互的操作出现KeeperException异常时均会导致abort；

7.在close region时，如果出现异常，比如：不能成功的flush memstore；

8.Flush memstore时，如果HLog发现该region已经在flush则会强制终止JVM，采用的是Runtime.getRuntime().halt(1)方法，该方法不会执行正常退出的关闭钩子，从而不会flush RS的所有region，也不会迁移region，只有等待ZK的session超时后master才会发现该RS不可用，做迁移工作。

 

总结

Hbase挂掉的可能性有很多，主要由zk或者hdfs的问题导致，因此zk、hdfs的可用对于hbase极其重要，关于zk：

1.zk如果停止了服务则在很多时候会导致master、rs挂掉，hbase集群基本上就失去了服务的能力，因此zk一定要是稳定可靠的，当client已经于rs建立了链接，这时zk挂掉，如果不进行split等小数与zk交互失败会导致触发rs的abort()的操作时rs还是可以提供服务的；

2.如果rs/master进行了长时间的gc或者改动了服务器时间，导致出现zk的session超时会导致rs/master停止服务，目前已经出现了2次因为服务器时间变化导致hbase停止服务的事故;

3.别轻易人为改变zk的hbase节点数据，master/rs在进行很多操作时会比较依赖zk的数据，如果发现不符合预期可能会导致master/rs停止服务，尤其是master。

 

    Master通过ZK知道RS是否可用，一般情况下RS在停止服务时均会正常退出，在正常退出时会从ZK中删除/hbase/rs/$regionserver的节点，Master会监听该节点的被删除，从而较快的(速度取决于所有region关闭时间)对该RS负责的region进行重新分配，如果是强制退出，比如 kill -9或者出现HRegionServer挂掉的第8条时则只有等待ZK的session超时时才会删除RS在ZK的节点（RS在ZK中添加节点时采用的是CreateMode.EPHEMERAL模式，该模式创建的节点会在session关闭时自动删除），那时Master才会进行重新assign。

    Kill RS的进程也是正常退出（不能使用kill -9强制退出），RS使用Runtime的addShutdownHook方法注册了jvm关闭钩子，在关闭钩子中会执行RS的退出逻辑，实际上hbase-daemon.sh的停止RS就是采用kill。