hbase無法啟動問題處理
點擊上方“IT那活兒”，關注后了解更多內(nèi)容，不管IT什么活兒，干就完了！?。?/span>
某日接到客戶反映hbase的測試環(huán)境無法啟動故障。最終定位原因為hbase regions負載過大崩潰，測試人員在恢復失敗后對zk實例刪除了一個，導致zk實例數(shù)據(jù)異常最終無法正常啟動完成，進一步導致hbase無法恢復啟動。恢復啟動后發(fā)現(xiàn)hbase的regions數(shù)量過多，單節(jié)點超過5000 regions，后續(xù)對集群進行優(yōu)化，清理過期歷史數(shù)據(jù)，釋放regions至正常水平，最終單節(jié)點承載數(shù)約1000regions左右。雖然此次處理的為測試環(huán)境，但處理hbase數(shù)據(jù)庫這種zk+hdfs+hbase常規(guī)綜合架構問題的思路可以分享給大家，于是將此次問題處理的主要流程及思考，結合zookeeper及hbase相關各組件的原理介紹，分享如下。
1. 登錄CM管理界面，發(fā)現(xiàn)登錄正常，但是集群處于關閉狀態(tài)。2. 檢查集群節(jié)點磁盤狀態(tài)，發(fā)現(xiàn)狀態(tài)正常，未有磁盤滿的節(jié)點情況出現(xiàn)。3. 嘗試對zookeeper服務進行啟動，發(fā)現(xiàn)無法啟動，報錯拒接連接。操作解析：因hbase的運行底層是依賴zookeeper組件存儲hbase運行所需的關鍵信息的，比如當前活動master節(jié)點、backup-masters節(jié)點、table名稱信息等，所以我們啟動hbase服務之前，前提一定是zookeeper服務啟動而且運行正常。日常處理某些hbaes異常故障或者性能問題時，如果hbase側(cè)排查未發(fā)現(xiàn)明顯問題，此時也可以轉(zhuǎn)方向查看hbase所依賴的zookeeper組件或者hdfs組件是否有問題。4. 檢查zookeeper實例，發(fā)現(xiàn)zk的實例被刪除了一個，進一步檢查zk的數(shù)據(jù)目錄，發(fā)現(xiàn)有一個log文件大小為0，懷疑此最新的異常log導致zk無法啟動。5. 對zk的節(jié)點數(shù)進行恢復，并將異常的log文件log.d161f9進行刪除，同時將次新的一個數(shù)據(jù)文件和snapshot文件scp到新加入的zk節(jié)點數(shù)據(jù)目錄。操作解析：zookeeper的運行中會定時將全量數(shù)據(jù)形成一個快照存放在zookeeper配置的數(shù)據(jù)目錄dataDir中，命名snapshot.<當前事務ID>，全量后續(xù)zk中的的變化會存儲在一個叫l(wèi)og.<當前事務ID>中。所以zookeeper的正常運行其實只需要最近一次的snapshot和log文件，就能保證其數(shù)據(jù)的完整性，而且所有zk的節(jié)點的數(shù)據(jù)是一致的，如果某個節(jié)點數(shù)據(jù)異常，是可以將leader節(jié)點的dataDir中的最新snapshot和log文件復制到異常節(jié)點來進行啟動恢復的。6. 再次對處理后的zookeeper服務進行啟動，已能夠成功啟動服務。7. zookeeper啟動完成后，使用zkCli.sh命令行進入zk目錄，ls查看之前的文件，/hbase所使用的目錄均正常，數(shù)據(jù)未丟失。8. 恢復hdfs服務，使用CM界面對hdfs服務進行啟動，啟動成功。操作解析：hbase是一個數(shù)據(jù)庫，數(shù)據(jù)庫的運行會依賴文件系統(tǒng)，hbase所依賴的文件系統(tǒng)即是hdfs，所以啟動hbase之前，一定要保證hdfs的服務啟動且運行正常的。同理日常生產(chǎn)中有些hbase的性能問題，我們同樣可以從hdfs側(cè)的方向同步進行排查。9. 恢復hbase服務，對hbase服務進行啟動，啟動成功。10. 使用hbase shell命令行進入對hbase服務進行測試，發(fā)現(xiàn)異常報錯regions not online出現(xiàn)。11. 檢查hbase-master日志，發(fā)現(xiàn)存在大量的reigons online信息。12. 此時登錄CM界面和hbase-master web界面查看，也發(fā)現(xiàn)hbase存在大量的regions還在transition狀態(tài)，而且超過了水位線。 13. 懷疑hbase出現(xiàn)regions過載，導致啟動后大量的regions需要重新上線，于是等待所有的reigons逐漸上線完成。操作解析：當hbase運行很久且存在大量數(shù)據(jù)時，hbase服務雖然啟動完成了，但是初始化進行大量的表和reigons上線其實是很耗時的，如果日常維護時發(fā)現(xiàn)hbase啟動后立即進行表數(shù)據(jù)的查詢發(fā)現(xiàn)報錯了，千萬不要盲目再次進行重啟，一定先檢查master日志看hbase集群是否還在初始化中，在擁有大量的表和regions的hbase集群中，hbase的完全啟動可能需要花費幾分鐘甚至幾十分鐘才能完成。14. 上線完成后，hbase服務恢復正常，查詢已能夠正常返回結果，但集群共計10874個regions，共計2個節(jié)點，一個節(jié)點超過了5000+regions，比正常水平的單節(jié)點維持800-1000regions的建議值高了5倍以上。15. 因hbase負載嚴重過載，與業(yè)務人員討論后，確定了清理過期測試數(shù)據(jù)的方案，釋放集群的regions數(shù)量，對2021年以前的所有表進行刪除。16. 清理完成后，再次檢查regions總數(shù)，集群總regions數(shù)量已經(jīng)2264個了，平均單節(jié)點1100個左右，基本處于正常水平。操作解析：在官方的建議中，hbase的regionserver節(jié)點承載的reigons建議值是低于400，在實際使用和生產(chǎn)環(huán)境中，我們認為JVM設置最大32G時，低于1000個reigons是一個正常且安全的值（因為如果按官方低于400部署集群的話，集群所需的機器投入會更多）。當hbase出現(xiàn)性能問題時，我們可以首先統(tǒng)計各個regionserver的承載regions數(shù)量，過多的regions存在某個reigonserver上時，就容易出現(xiàn)訪問熱點問題，集群的請求就會不平衡，這是日常最常見的hbase性能問題。17. 至此，hbase服務無法啟動的問題恢復完成，CM界面上所有的服務均啟動恢復完畢，故障處理完成。因為測試集群機器數(shù)量無法滿足最低3節(jié)點原因，部分組件存在黃色告警信息，可忽略。
此次故障初步分析根本原因為hbase集群在進行相關寫入測試時，有大量的預分區(qū)和數(shù)據(jù)寫入，沒有及時進行清理，時間久了導致hbase因負載過高而崩潰。
崩潰后測試人員嘗試進行恢復但是失敗，期間進行了zk實例的刪除，zk異常啟動時，寫入log失敗導致出現(xiàn)了大小為0的最新log文件，進一步導致最終zk無法正常啟動。
1. 對hbase歷史的數(shù)據(jù)進行清理，釋放集群的regions數(shù)量，維持在較健康的水平（已完成）；
2. 測試人員在后續(xù)測試后，及時進行hbase表及數(shù)據(jù)的清理，避免多人大量數(shù)據(jù)寫入導致hbase負載過高而崩潰，清理數(shù)據(jù)方法為truncate ‘tablename’（已通知測試人員）；
3. 建議測試環(huán)境的重要權限進行人員管控，CM管理界面的admin密碼不要讓過多人員有權進行操作，避免再次出現(xiàn)誤刪除zookeeper實例或者其他實例的問題。
1. hbase集群的運行通常是一個zk+hdfs+hbase綜合的架構，處理hbase問題時，一定不要單只看hbase組件，綜合zookeeper和hdfs組件一起分析往往有奇效；
2. zookeeper組件在此綜合架構中屬于最底層，建議部署時只作為hdfs和hbase組件依賴使用，不要用于其他業(yè)務數(shù)據(jù)的存儲使用，避免zk的問題影響到整個hdfs和hbase集群；
3. 文中hbase regionserver建議承載reigons在1000以內(nèi)是基于JVM設置32G的前提下的，如果環(huán)境JVM過小，承載regions的數(shù)量建議也對應減少，另regionserver的JVM不建議高于32G，避免GC的時機過久導致服務異常。
文章版權歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/129575.html
