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參數調整 

來源： http://lib.csdn.net/article/hbase/50253