hbase集群regionserver死亡分析
这是一次生产hbase事故。那天在上海出差，同事打电话说生产hbase 4个regionserver 都挂了，master活着，听到这个信息心情非常沉重，这么久还没发生过这样的事，立马让同事把regionserver重启，把生产日志全部拿下来分析。那天在上海办公室看了2个小时日志分析原因。以下为分析日志及过程：
从日志中可以看到宕机前频繁的大批量的数据查询
文章图片
hbase zookeeper客户端session过期
文章图片
hbase regionserver jvm gc时间超过三分钟
文章图片
hbase regionserver日志中报找不到/hbase/WALs目录，我检查了那几天hdfs文件系统均为正常
文章图片
后面排查应用发现为一个新业务用户在spark上运行了一个分析任务做大批量的入库查询动作，停掉后服务正常。
结论：regionserver全部宕机是由于任务进行大批量数据的读写造成regionserver服务GC时间过长超过 regionserver zookeeper session最大超时时间（regionserver zookeeper session 超时时间设为2min）,zookeeper会认为 hbase regionserver已死，master通知其它节点接管，其他regionserver会读取wal进行恢复regions，处理完的wal，会把wal文件删除，hbase regionserver恢复过来，找不到wal报错，从zookeeper得知自己已死就会关闭自己。
后续改进方案：服务端 hbase quota表限流 ，hbase进行扩容，批量实时hbase物理隔离使用regionserver groups,有条件的可以多hbase集群分离。 客户端 代码修改使用官方推荐api，控制查询数据的范围，控制并发量，批量查询入库提前更管理员沟通，方案可行行验证。
【hbase集群regionserver死亡分析】
推荐阅读
- federation--kubernetes集群联邦的实现
- (1)redis集群原理及搭建与使用(1)
- mvcc原理和hbase实现
- k8s|k8s(六)（配置管理与集群安全机制）
- hbase安装2019-03-11
- 啥是负载均衡、高并发、分布式、集群（）
- 三十一、|三十一、 Elasticsearch集群搭建部署及配置
- springBoot2.*使用redis集群/单机方法
- centos7|centos7 redis安装/集群部署/slots迁移
- CentOS|CentOS 7.2搭建FastDFS 分布式文件系统，实现高可用集群