一次Hbase集群故障记录

周天早上6点钟，接到了公司的报警电话，异常数量超过了阈值，然后组长说他那边的网络有点问题，让人看看是什么原因，连上VPN后，发现是HBase的Table对象找不到，无法连接Hbase集群。

我们组是业务组，问题定位到这里剩下的只能靠架构组了，架构组里面有专门负责Hbase的，只能让他们处理了。不过个人对技术比较感兴趣，想弄明白这次问题的原因，就去咨询了架构组的人。

提到沟通，那又是另外一门学问了。

在进行问题描述之前，可以先看下这篇问题：HBase架构细节，搞明白Hbase的一些原理。一般HBase在Master挂掉的时候会重新进行Master选举，在RegionServer挂掉的时候，也会进行故障恢复，反正就是Hbase有高可用的特性了。

但是如果是Zookeeper集群挂掉，导致Hbase集群挂掉，还能高可用吗？

问题

Zookeeper集群内部进行Leader选举，(由于网络抖动)，这段时间内ZK集群不可用，紧接着波及了依赖ZK集群的其它服务，就比如说Hbase集群，然后整个Hbase集群挂掉了。

Hbase集群为什么恢复了一个多小时？架构组的人说的是他们的告警出了问题，所以处理的比较慢了，详细情况会出一个事件报告。

经过我不断询问，目前只给了这多信息，那些人在北京，在QQ上问问题的时候爱理不理的，真晕。既然暂时从他们那边也获取不到真实信息，那只能自己分析了。

分析

Zookeeper的Leader选举一般持续多长时间？

Hbase整个集群挂掉了，如何恢复？

ZK自测

我自己在本机测试，ZooKeeper的Leader重新选举时间很短，但是如果有数据的话，可能要把数据同步到其它的节点时间会比较久。但是如果时间太长，那就是设计之初考虑的较少导致的。

另外在Zookeeper集群由可用变为不可用状态的时候，客户端与ZK服务器的连接也会断掉，并且不断的连接重试。

如果断开连接之后重连耗时太长，超过了会话过期时间，服务器任务会话已经过期，就会进行会话清理。会话过期之后，即使重新连接成功，服务器还是会告知客户端会话过期，请重新连接。然后客户端需要重新恢复临时数据。

但是如果是ZK服务器集群不可用导致的无法重连，那么….客户端还是会不断的重试，直到重连成功。

客户端：

服务端：

当新的ZK节点重新加入的时候：可以看到这个节点的Leader选举花费了295s，也就是4分钟。而新加入的节点在Leader选举上，只花费了0.2s

关于ZK Leader重新选举花费的时间，与ZK上的数据量也有一定的关系。另外看网络和集群的量了。具体时间架构组说的不好估计，但大部分在10s钟之内可以搞得定。当然可能有一些意外的情况

真实情况

ZK集群因网络抖动导致

公司内部的问题排查记录，遇到问题的时候，先说问题与影响。

问题：集群内通信断开，导致服务器重新Leader选举，选举耗时21672ms

影响：整个Hbase集群的RegionServer及YARN集群挂掉

虽然Leader选举只花费了30s，但是从集群延迟变大直到ZK集群正常工作，期间5分钟内，集群内通信断断续续，可根据日志查看。

HBase恢复

早上6：35分钟，张钧打电话说Hbase有问题，发现RegionServer下线，然后查看HDFS情况正常，首先启动Hbase集群，然后排查具体问题。

原因：Replication模块复制点位信息存储在ZK中，因网络抖动导致的ZK不可用，RegionServer连续4次访问ZK都无法连接，每次sleep 1秒钟，从而RegionServer下线，影响多台RegionServer服务器。

解决方案：6:48分启动Hbase，region打开耗费了大约50分钟，影响持续到7：30分

反思：

• Hbase宕机不是负责Hbase的人第一时间发现的，是业务通知的，没有收到报警是因为报警关闭了，这个属于工作的重大失误
• Region打开十分耗时，实际上很多Region没有打开的紧急性，比如非当月表的Region，访问需求低。

今后采取措施：

• 报警已经加上，对于报警关闭的事情应该加以限制，从系统上优化这个事情，不应该关闭
• Region优先级的调整，及一些框架上的优化