hbase故障如何處理

這篇文章主要為大家展示了“hbase故障如何處理”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“hbase故障如何處理”這篇文章吧。

一、故障現象

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）

四、最終原因：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故障如何處理”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！