异常导致的退出会通过接口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。