这篇文章主要为大家展示了“hbase故障如何处理”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让小编带领大家一起研究并学习一下“hbase故障如何处理”这篇文章吧。
一、故障现象
首先regionserver频繁爆出两类错误：
wal.FSHLog: Error syncing, request close of WAL:
以及出现错误：
org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 293 actions: NotServingRegionException: 42 times
以及出现regionserver dead 故障：
Region server exitingjava.lang.RuntimeException: HRegionServer Aborted既然通过优化hbase本身无法解决regionserver频繁挂掉的原因，那就必须将分析扩大到hbase相关的进程。与hbase密切相关的是zookeeper。我们详细分析看zk的日志，比如之前regionserver在03:03:17时间出现了regionserver dead 报错信息，因此我们分析zk在这个时间段前后的日志。从日志看到regionserver与zk的超时时间是40秒，“the sessions negotiated with zookeeper from dead regionserver were of 40s”。然后再查看regionserver的gc时长，确实超过了40秒。
gc时间过长，超过40秒的maxSessionTimeout时间，使得zk认为regionserver已经挂掉dead；
zk返回dead region到master，master就让其他regionserver负责dead regionserver的regions；
其他regionserver会读取wal进行恢复regions，处理完的wal，会把wal文件删除；
dead regionserver的gc完成，并且恢复服务之后，找不到wal，已经产生上面截图中的报错（wal.FSHLog: Error syncing, request close of WAL）；
dead regionserver从zk得知自己dead，就关闭自己（Region server exiting，java.lang.RuntimeException: HRegionServer Aborted）
四、最终原因：tickTime超时
经过上面的分析，是gc时间超过40秒的maxSessionTimeout导致的regionserver挂掉。但是，我们就很纳闷了，因为我们设置的zookeeper.session.timeout超时时间为240秒，远远超过40秒时间。非常奇怪呀！
经过hbase社区求助，以及google类似的问题，最终找到原因（详细链接，请参考：https://superuser.blog/hbase-dead-regionserver/）：
原来我们的HBase 并没有设置tickTime，最终hbase与zk的会话最大超时时间并不是zookeeper.session.timeout参数决定的，而是有zk的maxSessionTimeout决定。zk会根据minSessionTimeout与maxSessionTimeout两个参数重新调整最后的超时值，minSessionTimeout=2*tickTime, maxSessionTimeout=20*tickTime。我们的大数据集群，zk的tickTime设置为默认值（2000ms）2秒，因此，最终hbase 与 zk的超时时间就为40秒。
经过调整zk的tickTime为6秒，相应的zookeeper.session.timeout为120秒，最终解决regionserver 频繁挂掉的故障。
以上是“hbase故障如何处理”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注编程网行业资讯频道！
