Hbase 日常運維


日常維護的命令

    1,major_compact 'testtable',通常生產環境會關閉自動major_compact(配置文件中hbase.hregion.majorcompaction設 為0),選擇一個晚上用戶少的時間窗口手工major_compact,如果hbase更新不是太頻繁,可以一個星期對所有表做一次 major_compact,這個可以在做完一次major_compact后,觀看所有的storefile數量,如果storefile數量增加到 major_compact后的storefile的近二倍時,可以對所有表做一次major_compact,時間比較長,操作盡量避免高鋒期。

    2,flush 'testtable',將所有memstore刷新到hdfs,通常如果發現regionserver的內存使用過大,造成該機的 regionserver很多線程block,可以執行一下flush操作,這個操作會造成hbase的storefile數量劇增,應盡量避免這個操 作,還有一種情況,在hbase進行遷移的時候,如果選擇拷貝文件方式,可以先停寫入,然后flush所有表,拷貝文件。

    3,balance_switch true或者balance_switch flase,配置master是否執行平衡各個regionserver的region數量,當我們需要維護或者重啟一個regionserver時,會 關閉balancer,這樣就使得region在regionserver上的分布不均,這個時候需要手工的開啟balance。


1.1監控Hbase運行狀況 
1.1.1操作系統 
1.1.1.1IO 
a.群集網絡IO,磁盤IO,HDFS IO 
IO越大說明文件讀寫操作越多。當IO突然增加時,有可能:1.compact隊列較大,集群正在進行大量壓縮操作。 
2.正在執行mapreduce作業 
可以通過CDH前台查看整個集群綜合的數據或進入指定機器的前台查看單台機器的數據: 
這里寫圖片描述 
b.Io wait 
磁盤IO對集群的影響比較大,如果io wait時間過長需檢查系統或磁盤是否有異常。通常IO增加時io wait也會增加,現在FMS的機器正常情況io wait在50ms以下 
跟主機相關的指標可以在CDH前台左上角先點“主機”選項卡然后選要查看的主機: 
這里寫圖片描述 
1.1.1.2CPU 
如果CPU占用過高有可能是異常情況引起集群資源消耗,可以通過其他指標和日志來查看集群正在做什么。 
1.1.1.3內存 
1.1.2 JAVA 
GC 情況 
regionserver長時間GC會影響集群性能並且有可能會造成假死的情況 
1.1.3重要的hbase指標 
1.1.3.1region情況 
需要檢查 
1.region的數量(總數和每台regionserver上的region數) 
2.region的大小 
如果發現異常可以通過手動merge region和手動分配region來調整 
從CDH前台和master前台以及regionServer的前台都可以看到region數量,如master前台: 
這里寫圖片描述 
在region server前台可以看到storeFile大小: 
這里寫圖片描述 
1.1.3.2緩存命中率 
緩存命中率對hbase的讀有很大的影響,可以觀察這個指標來調整blockcache的大小。 
從regionserver web頁面可以看到block cache的情況: 
這里寫圖片描述 
1.1.3.3讀寫請求數 
通過讀寫請求數可以大概看出每台regionServer的壓力,如果壓力分布不均勻,應該檢查regionServer上的region以及其它指標 
master web上可以看到所以regionServer的讀寫請求數 
這里寫圖片描述 
regionServer上可以看到每個region的讀寫請求數 
這里寫圖片描述 
1.1.3.4壓縮隊列 
壓縮隊列存放的是正在壓縮的storefile,compact操作對hbase的讀寫影響較大 
通過cdh的hbase圖表庫可以看到集群總的壓縮隊列大小: 
這里寫圖片描述 
可以通過CDH的hbase主頁查詢compact日志: 
這里寫圖片描述 
點擊“壓縮”進入: 
這里寫圖片描述 
1.1.3.5刷新隊列 
單個region的memstore寫滿(128M)或regionServer上所有region的memstore大小總合達到門限時會進行flush操作,flush操作會產生新的storeFile 
同樣可以通過CDH的hbase前台查看flush日志: 
這里寫圖片描述 
1.1.3.6rpc調用隊列 
沒有及時處理的rpc操作會放入rpc操作隊列,從rpc隊列可以看出服務器處理請求的情況 
1.1.3.7文件塊保存在本地的百分比 
datanode和regionserver一般都部署在同一台機器上,所以region server管理的region會優先存儲在本地,以節省網絡開銷。如果block locality較低有可能是剛做過balance或剛重啟,經過compact之后region的數據都會寫到當前機器的datanode,block locality也會慢慢達到接近100: 
這里寫圖片描述 
1.1.3.8內存使用情況 
內存使用情況,主要可以看used Heap和memstore的大小,如果usedHeadp一直超過80-85%以上是比較危險的 
memstore很小或很大也不正常 
從region Server的前台可以看到: 
這里寫圖片描述 
1.1.3.9slowHLogAppendCount 
寫HLog過慢(>1s)的操作次數,這個指標可以作為HDFS狀態好壞的判斷 
在region Server前台查看: 
這里寫圖片描述 
1.1.4CDH檢查日志 
CDH有強大的系統事件和日志搜索功能,每一個服務(如:hadoop,hbase)的主頁都提供了事件和告警的查詢,日常運維除了CDH主頁的告警外,需要查看這些事件以發現潛在的問題: 
這里寫圖片描述 
選擇“事件搜索”中的標簽(“警報”、“嚴重”)可以進入相關的事件日志,如“嚴重”: 
這里寫圖片描述 
1.2檢查數據一致性以及修復方法 
數據一致性是指: 
1.每個region都被正確的分配到一台regionserver上,並且region的位置信息及狀態都是正確的。 
2.每個table都是完整的,每一個可能的rowkey 都可以對應到唯一的一個region. 
1.2.1檢查 
hbase hbck 
注:有時集群正在啟動或region正在做split操作,會造成數據不一致 
hbase hbck -details 
加上–details會列出更詳細的檢查信息,包括所以正在進行的split任務 
hbase hbck Table1 Table2 
如果只想檢查指定的表,可以在命令后面加上表名,這樣可以節省操作時間 
CDH 
通過CDH提供的檢查報告也可以看到hbck的結果,日常只需要看CDH hbck的報告即可: 
這里寫圖片描述 
選擇“最近的Hbck結果”: 
這里寫圖片描述 
1.2.2修復 
1.2.2.1局部的修復 
如果出現數據不一致,修復時要最大限度的降低可能出現的風險,使用以下命令對region進行修復風險較低: 
1.2.2.1.1hbase hbck -fixAssignments 
修復region沒有分配(unassigned),錯誤分配(incorrectly assigned)以及多次分配(multiply assigned)的問題 
1.2.2.1.2hbase hbck -fixMeta 
刪除META表里有記錄但HDFS里沒有數據記錄的region 
添加HDFS里有數據但是META表里沒有記錄的region到META表 
1.2.2.1.3hbase hbck -repairHoles 
等價於:hbase hbck -fixAssignments -fixMeta -fixHdfsHoles 
-fixHdfsHoles的作用: 
如果rowkey出現空洞,即相鄰的兩個region的rowkey不連續,則使用這個參數會在HDFS里面創建一個新的region。創建新的region之后要使用-fixMeta和-fixAssignments參數來使用掛載這個region,所以一般和前兩個參數一起使用 
1.2.2.2Region重疊修復 
進行以下操作非常危險,因為這些操作會修改文件系統,需要謹慎操作! 
進行以下操作前先使用hbck –details查看詳細問題,如果需要進行修復先停掉應用,如果執行以下命令時同時有數據操作可能會造成不可期的異常。 
1.2.2.2.1hbase hbck -fixHdfsOrphans 
將文件系統中的沒有metadata文件(.regioninfo)的region目錄加入到hbase中,即創建.regioninfo目錄並將region分配到regionser 
1.2.2.2.2hbase hbck -fixHdfsOverlaps 
通過兩種方式可以將rowkey有重疊的region合並: 
1.merge:將重疊的region合並成一個大的region 
2.sideline:將region重疊的部分去掉,並將重疊的數據先寫入到臨時文件,然后再導入進來。 
如果重疊的數據很大,直接合並成一個大的region會產生大量的split和compact操作,可以通過以下參數控制region過大: 
-maxMerge 合並重疊region的最大數量 
-sidelineBigOverlaps 假如有大於maxMerge個數的 region重疊, 則采用sideline方式處理與其它region的重疊. 
-maxOverlapsToSideline 如果用sideline方式處理重疊region,最多sideline n個region . 
1.2.2.2.3hbase hbck -repair 
以下命令的縮寫: 
hbase hbck -fixAssignments -fixMeta -fixHdfsHoles -fixHdfsOrphans -fixHdfsOverlaps -fixVersionFile –sidelineBigOverlaps 
可以指定表名: 
hbase hbck -repair Table1 Table2 
1.2.2.2.4hbase hbck -fixMetaOnly –fixAssignments 
如果只有META表的region不一致,則可以使用這個命令修復 
1.2.2.2.5hbase hbck –fixVersionFile 
Hbase的數據文件啟動時需要一個version file,如果這個文件丟失,可以用這個命令來新建一個,但是要保證hbck的版本和Hbase集群的版本是一樣的 
1.2.2.2.6hbase org.apache.hadoop.hbase.util.hbck.OfflineMetaRepair 
如果ROOT表和META表都出問題了Hbase無法啟動,可以用這個命令來創建新的ROOT和META表。 
這個命令的前提是Hbase已經關閉,執行時它會從hbase的home目錄加載hbase的相關信息(.regioninfo),如果表的信息是完整的就會創建新的root和meta目錄及數據 
1.2.2.2.7hbase hbck –fixSplitParents 
當region做split操作的時候,父region會被自動清除掉。但是有時候子region在父region被清除之前又做了split。造成有些延遲離線的父region存在於META表和HDFS中,但是沒有部署,HBASE又不能清除他們。這種情況下可以使用此命令重置這些在META表中的region為在線狀態並且沒有split。然后就可以使用之前的修復命令把這個region修復 
1.3手動merge region 
進行操作前先將balancer關閉,操作完成后再打開balancer 
經過一段時間的運行之后有可能會產生一些很小的region,需要定期檢查這些region並將它們和相鄰的region合並以減少系統的總region數,減少管理開銷 
合並方法: 
1.找到需要合並的region的encoded name 
2.進入hbase shell 
3.執行merge_region ‘region1’,’region2’ 
1.4手動分配region 
如果發現台regionServer資源占用特別高,可以檢查這台regionserver上的region是否存在過多比較大的region,通過hbase shell將部分比較大的region分配給其他不是很忙的regions server: 
move ‘regionId’,’serverName’ 
例: 
move ‘54fca23d09a595bd3496cd0c9d6cae85’,’vmcnod05,60020,1390211132297’ 
1.5手動major_compact 
進行操作前先將balancer關閉,操作完成后再打開balancer 
選擇一個系統比較空閑的時間手工major_compact,如果hbase更新不是太頻繁,可以一個星期對所有表做一次 major_compact,這個可以在做完一次major_compact后,觀看所有的storefile數量,如果storefile數量增加到 major_compact后的storefile的近二倍時,可以對所有表做一次major_compact,時間比較長,操作盡量避免高鋒期 
注:fms現在生產上開啟了自動major_compact,不需要做手動major compact 
1.6balance_switch 
balance_switch true 打開balancer 
balance_switch flase 關閉balancer 
配置master是否執行平衡各個regionserver的region數量,當我們需要維護或者重啟一個regionserver時,會關閉balancer,這樣就使得region在regionserver上的分布不均,這個時候需要手工的開啟balance。

1.7regionserver重啟 
graceful_stop.sh –restart –reload –debug nodename 
進行操作前先將balancer關閉,操作完成后再打開balancer 
這個操作是平滑的重啟regionserver進程,對服務不會有影響,他會先將需要重啟的regionserver上面的所有 region遷移到其它的服務器,然后重啟,最后又會將之前的region遷移回來,但我們修改一個配置時,可以用這種方式重啟每一台機子,對於hbase regionserver重啟,不要直接kill進程,這樣會造成在zookeeper.session.timeout這個時間長的中斷,也不要通過 bin/hbase-daemon.sh stop regionserver去重啟,如果運氣不太好,-ROOT-或者.META.表在上面的話,所有的請求會全部失敗 
1.8regionserver關閉下線 
bin/graceful_stop.sh nodename 
進行操作前先將balancer關閉,操作完成后再打開balancer 
和上面一樣,系統會在關閉之前遷移所有region,然后stop進程。 
1.9flush表 
所有memstore刷新到hdfs,通常如果發現regionserver的內存使用過大,造成該機的 regionserver很多線程block,可以執行一下flush操作,這個操作會造成hbase的storefile數量劇增,應盡量避免這個操 作,還有一種情況,在hbase進行遷移的時候,如果選擇拷貝文件方式,可以先停寫入,然后flush所有表,拷貝文件 
1.10Hbase遷移 
1.10.1copytable方式 
bin/hbase org.apache.hadoop.hbase.mapreduce.CopyTable –peer.adr=zookeeper1,zookeeper2,zookeeper3:/hbase ‘testtable’ 
這個操作需要添加hbase目錄里的conf/mapred-site.xml,可以復制hadoop的過來。 
1.10.2Export/Import 
bin/hbase org.apache.hadoop.hbase.mapreduce.Export testtable /user/testtable [versions] [starttime] [stoptime] 
bin/hbase org.apache.hadoop.hbase.mapreduce.Import testtable /user/testtable 
1.10.3直接拷貝hdfs對應的文件 
首先拷貝hdfs文件,如bin/hadoop distcp hdfs://srcnamenode:9000/hbase/testtable/ hdfs://distnamenode:9000/hbase/testtable/ 
然后在目的hbase上執行bin/hbase org.jruby.Main bin/add_table.rb /hbase/testtable 
生成meta信息后,重啟hbase 
2Hadoop日常運維 
2.1監控Hadoop運行狀況 
1.nameNode、ResourseManager內存(namenode要有足夠內存) 
2.DataNode和NodeManager運行狀態 
3.磁盤使用情況 
4.服務器負載狀態 
2.2檢查HDFS文件健康狀況 
命令:hadoop fsck 
2.3開啟垃圾箱(trash)功能 
trash功能它默認是關閉的,開啟后,被你刪除的數據將會mv到操作用戶目錄的”.Trash”文件夾,可以配置超過多長時間,系統自動刪除過期數據。這樣一來,當操作失誤的時候,可以把數據mv回來 
3本項目場景下的hbase參數調整 
這里寫圖片描述



免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM