记：Hbase一次令人头疼的宕机

宕机前日志：（分析集群在做什么）

图一：

上图是hbase节点挂掉之前1秒的日志，由日志可以看出系统是在做compaction,也就是hbase底层数据原文件的合并，包括无效数据文件的删除，新增数据文件合并

图二：

从上边这幅图可以看出，同时在做合并删除的表不只一张，compaction是非常耗时切工作时很耗资源的操作，并且在做compaction时RS（Region server）会挂起一段时间，也就是说hbase对外服务会有延迟，下边会有说明（特别注意这里，st_prod也在做compaction，这一点很重要，下边会有说明）

图三：

这是官网的截图，从上边这句话，官网很委婉的告诉我们，hbase的compaction操作是会造成系统挂掉，建议我们关掉自动的compaction，设置cron job在空闲时做此类操作

图四：

图四是挂机时抛出的日志，是紧接着compaction操作打出的日志，这时候hbase节点已经挂掉，按理说单单做compaction操作就会让hbase挂机肯定是不合理的，因为我们的系统每天都在自动做compaction,可是挂机这个时间点很微妙，宕机这几次都发生在凌晨1.10分左右，几次宕机时跑的都是toc spark任务的第21步，就是下图

图五

这一步是多线程的操作（700），这一步是读取数据的操作，由于读的数据依然是存在hbase，也就是说这个时间hbase的RS服务同时在做三件高并发的事情，1、外部接口调用的请求 2、Hbase自身做的compaction 3、toc任务  ,如果单单是高并发，那集群高并发的时候应该也很多，下图又是导致宕机的一个关键点：

图六

上图是spark任务报错时跑的代码，这段sql在从st_prod拉数据，而存储st_prod的hdfs的文件访问都是单进程的（hdfs存储文件都是单进程操作），也就是我的底层数据文件在做compaction操作时，toc任务的read文件的操作就要等待，而compaction又是一个很耗时间的操作,所以出现一种情况时，我的toc spark任务起的读数据的task都在wait，由于一直在等待，zookeeper迟迟得不到返回值，zookeeper发生timeout，zookeeper默认这个hbase节点已经挂掉，最终zookeeper停止对这台hbase节点提供服务，这台hbase节点也就完全挂掉

宕机分析结论：

1、hbase compaction操作在集群访问频繁时，有宕机风险  （查阅很多资料都是这个结论，包括官网）

2、特殊情况下的compaction和toc spark任务在操作同一张表，发生等待，导致zookeeper timeout，最终心跳丢失，节点挂掉（目前我们挂机都是在在跑同一个任务的同一个步骤）

3、节点在很长一段时间花大精力在做GC，导致GC处在一个很高的状态并且持续好久，当然这一步很大程度上也是有1、2步导致