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