首页 > 大数据 > Hadoop > hbase 故障的处理方案。 (转载文章)
最近遭遇了, hbase 节点故障的事故次数有点多了,结合现场。
发现网上这票文章, , 感谢原作者。
参考 : https://cloud.tencent.com/developer/article/1030070
1、 首先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 exiting java.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)
经过上面的分析,是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 频繁挂掉的故障。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/133735/viewspace-2222110/,如需转载,请注明出处,否则将追究法律责任。