最近遭遇了， 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）

四、最終原因：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 頻繁掛掉的故障。