Regionserver 頻繁掛掉故障處理實踐

更多騰訊海量技術文章， 請關注雲+社區：https://cloud.tencent.com/developer

作者：mikealzhou

導語：

近期騰訊雲的一家大客戶頻繁出現HBase regionserver 掛掉， 影響業務正常使用。 通過調整堆疊大小、gc優化、超時時間等都無法解決該問題。 經過細緻並綜合分析hbase regionserver、hbase master以及 zookeeper的日誌， 發現了問題所在：tickTime設置導致hbase超時時間錯誤。

一、故障現象

1、 首先regionserver頻繁爆出兩類錯誤：

以及出現錯誤：

2、然後出現regionserver死亡錯誤：

以及出現regionserver dead 故障：

Region server exitingjava.lang.RuntimeException: HRegionServer Aborted

二、故障分析與解決

從上述報錯可以看出， 引起regionserver 故障的主要原因集中在memstore， 因此首先想到是regionserver 的堆疊設置不合理或者是gc優化不合理。 因此， 我們將hbase以及regionserver 的堆疊都設置為16G， 然後對gc進行優化。 最終， HBase具體優化參數如下所示：

export HBASE_HEAPSIZE=16384export master_heapsize=8192export regionserver_heapsize=16384export HBASE_OPTS="$HBASE_OPTS -Xss512k -XX:PermSize=256m -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:MaxGCPauseMillis=50 -XX:GCPauseIntervalMillis=100 -XX:-OmitStackTraceInFastThrow -XX:MaxTenuringThreshold=1 -XX:ConcGCThreads=12 -XX:G1OldCSetRegionThresholdPercent=3 -XX:ParallelGCThreads=18 -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=20M -XX:+ParallelRefProcEnabled -XX:-ResizePLAB -XX:G1MixedGCCountTarget=16 -XX:InitiatingHeapOccupancyPercent=75 -XX:G1ReservePercent=5 -XX:G1NewSizePercent=8 -XX:G1HeapRegionSize=16m -XX:ErrorFile={{log_dir}}/hs_err_pid%p.log"export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS -Xmx{{master_heapsize}} -XX:PermSize=256m -XX:MaxPermSize=256m"export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS -XX:CMSInitiatingOccupancyFraction=70 -Xms{{regionserver_heapsize}} -Xmx{{regionserver_heapsize}}"

經過參數優化之後， regionserver 頻繁掛掉的情況有所改善。

但是， regionserver 還是出現了掛掉的情況， 只是比之前有改善。 因此通過優化堆疊以及gc， 並不能完全解決該問題。

三、分析故障原因

既然通過優化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秒。

總結原因：

（1）gc時間過長， 超過40秒的maxSessionTimeout時間， 使得zk認為regionserver已經掛掉dead；

（2）zk返回dead region到master， master就讓其他regionserver負責dead regionserver的regions；

（3）其他regionserver會讀取wal進行恢復regions， 處理完的wal， 會把wal檔刪除；

（4）dead regionserver的gc完成， 並且恢復服務之後， 找不到wal， 已經產生上面截圖中的報錯（wal.FSHLog: Error syncing, request close of WAL）；

（5）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 頻繁掛掉的故障。