1. 程式人生 > >Hbase運維參考(項目)

Hbase運維參考(項目)

操作系統 str sig map 參考 balance loading versions 一起

1 Hbase日常運維

1.1 監控Hbase運行狀況

1.1.1 操作系統

1.1.1.1 IO

  1. 群集網絡IO,磁盤IOHDFS IO

IO越大說明文件讀寫操作越多。當IO突然增加時,有可能:1.compact隊列較大,集群正在進行大量壓縮操作。

2.正在執行mapreduce作業

可以通過CDH前臺查看整個集群綜合的數據或進入指定機器的前臺查看單臺機器的數據:

技術分享

  1. Io wait

磁盤IO對集群的影響比較大,如果io wait時間過長需檢查系統或磁盤是否有異常。通常IO增加時io wait也會增加,現在FMS的機器正常情況io wait50ms以下

跟主機相關的指標可以在CDH前臺左上角先點“主機”選項卡然後選要查看的主機:

1.1.1.1 CPU

如果CPU占用過高有可能是異常情況引起集群資源消耗,可以通過其他指標和日誌來查看集群正在做什麽。

1.1.1.2 內存

1.1.1 JAVA

GC 情況

regionserver長時間GC會影響集群性能並且有可能會造成假死的情況

1.1.2 重要的hbase指標

1.1.2.1 region情況

需要檢查

  1. region的數量(總數和每臺regionserver上的region數)
  2. region的大小

如果發現異常可以通過手動merge region和手動分配region來調整

CDH前臺和master前臺以及regionServer的前臺都可以看到region數量,如master前臺:

技術分享

region server前臺可以看到storeFile大小:

技術分享

1.1.1.1 緩存命中率

緩存命中率對hbase的讀有很大的影響,可以觀察這個指標來調整blockcache的大小。

regionserver web頁面可以看到block cache的情況:

技術分享

1.1.1.2 讀寫請求數

通過讀寫請求數可以大概看出每臺regionServer的壓力,如果壓力分布不均勻,應該檢查regionServer上的region以及其它指標

master web上可以看到所以regionServer的讀寫請求數

regionServer上可以看到每個region的讀寫請求數

技術分享

regionServer上可以看到每個region的讀寫請求數

技術分享

1.1.1.3 壓縮隊列

壓縮隊列存放的是正在壓縮的storefile,compact操作對hbase的讀寫影響較大

通過cdh的hbase圖表庫可以看到集群總的壓縮隊列大小:

技術分享

可以通過CDH的hbase主頁查詢compact日誌:

技術分享

點擊“壓縮”進入:

技術分享

1.1.1.1 刷新隊列

單個region的memstore寫滿(128M)或regionServer上所有region的memstore大小總合達到門限時會進行flush操作,flush操作會產生新的storeFile

同樣可以通過CDH的hbase前臺查看flush日誌:

技術分享

1.1.1.1 rpc調用隊列

沒有及時處理的rpc操作會放入rpc操作隊列,從rpc隊列可以看出服務器處理請求的情況

1.1.1.2 文件塊保存在本地的百分比

datanode和regionserver一般都部署在同一臺機器上,所以region server管理的region會優先存儲在本地,以節省網絡開銷。如果block locality較低有可能是剛做過balance或剛重啟,經過compact之後region的數據都會寫到當前機器的datanode,block locality也會慢慢達到接近100:

技術分享

1.1.1.1 內存使用情況

內存使用情況,主要可以看used Heap和memstore的大小,如果usedHeadp一直超過80-85%以上是比較危險的

memstore很小或很大也不正常

region Server的前臺可以看到:

技術分享

1.1.1.1 slowHLogAppendCount

HLog過慢(>1s)的操作次數,這個指標可以作為HDFS狀態好壞的判斷

region Server前臺查看:

技術分享

1.1.1 CDH檢查日誌

CDH有強大的系統事件和日誌搜索功能,每一個服務(如:hadoop,hbase)的主頁都提供了事件和告警的查詢,日常運維除了CDH主頁的告警外,需要查看這些事件以發現潛在的問題:

技術分享

選擇“事件搜索”中的標簽(“警報”、“嚴重”)可以進入相關的事件日誌,如“嚴重”:

技術分享

1.1 檢查數據一致性以及修復方法

數據一致性是指:

  1. 每個region都被正確的分配到一臺regionserver上,並且region的位置信息及狀態都是正確的。
  2. 每個table都是完整的,每一個可能的rowkey 都可以對應到唯一的一個region.

1.1.1 檢查

hbase hbck

註:有時集群正在啟動或region正在做split操作,會造成數據不一致

hbase hbck -details

加上–details會列出更詳細的檢查信息,包括所以正在進行的split任務

hbase hbck Table1 Table2

如果只想檢查指定的表,可以在命令後面加上表名,這樣可以節省操作時間

CDH

通過CDH提供的檢查報告也可以看到hbck的結果,日常只需要看CDH hbck的報告即可:

技術分享

選擇“最近的Hbck結果”:

技術分享

1.1.1 修復

1.1.1.1 局部的修復

如果出現數據不一致,修復時要最大限度的降低可能出現的風險,使用以下命令對region進行修復風險較低:

1.1.1.1.1 hbase hbck -fixAssignments

修復region沒有分配(unassigned),錯誤分配(incorrectly assigned)以及多次分配(multiply assigned)的問題

1.1.1.1.1 hbase hbck -fixMeta

刪除META表裏有記錄但HDFS裏沒有數據記錄的region

添加HDFS裏有數據但是META表裏沒有記錄的region到META表

1.1.1.1.2 hbase hbck -repairHoles

等價於:hbase hbck -fixAssignments -fixMeta -fixHdfsHoles

-fixHdfsHoles的作用:

如果rowkey出現空洞,即相鄰的兩個region的rowkey不連續,則使用這個參數會在HDFS裏面創建一個新的region。創建新的region之後要使用-fixMeta和-fixAssignments參數來使用掛載這個region,所以一般和前兩個參數一起使用

1.1.1.1 Region重疊修復

進行以下操作非常危險,因為這些操作會修改文件系統,需要謹慎操作!

進行以下操作前先使用hbck –details查看詳細問題,如果需要進行修復先停掉應用,如果執行以下命令時同時有數據操作可能會造成不可期的異常。

1.1.1.1.1 hbase hbck -fixHdfsOrphans

將文件系統中的沒有metadata文件(.regioninfo)的region目錄加入到hbase中,即創建.regioninfo目錄並將region分配到regionser

1.1.1.1.1 hbase hbck -fixHdfsOverlaps

通過兩種方式可以將rowkey有重疊的region合並:

  1. merge:將重疊的region合並成一個大的region
  2. sideline:將region重疊的部分去掉,並將重疊的數據先寫入到臨時文件,然後再導入進來。

如果重疊的數據很大,直接合並成一個大的region會產生大量的split和compact操作,可以通過以下參數控制region過大:

-maxMerge <n> 合並重疊region的最大數量

-sidelineBigOverlaps 假如有大於maxMerge個數的 region重疊, 則采用sideline方式處理與其它region的重疊.

-maxOverlapsToSideline <n> 如果用sideline方式處理重疊region,最多sideline n個region .

1.1.1.1.1 hbase hbck -repair

以下命令的縮寫:

hbase hbck -fixAssignments -fixMeta -fixHdfsHoles -fixHdfsOrphans -fixHdfsOverlaps -fixVersionFile –sidelineBigOverlaps

可以指定表名:

hbase hbck -repair Table1 Table2

1.1.1.1.2 hbase hbck -fixMetaOnly –fixAssignments

如果只有META表的region不一致,則可以使用這個命令修復

1.1.1.1.1 hbase hbck –fixVersionFile

Hbase的數據文件啟動時需要一個version file,如果這個文件丟失,可以用這個命令來新建一個,但是要保證hbck的版本和Hbase集群的版本是一樣的

1.1.1.1.2 hbase org.apache.hadoop.hbase.util.hbck.OfflineMetaRepair

如果ROOT表和META表都出問題了Hbase無法啟動,可以用這個命令來創建新的ROOT和META表。

這個命令的前提是Hbase已經關閉,執行時它會從hbase的home目錄加載hbase的相關信息(.regioninfo),如果表的信息是完整的就會創建新的root和meta目錄及數據

1.1.1.1.1 hbase hbck –fixSplitParents

region做split操作的時候,父region會被自動清除掉。但是有時候子region在父region被清除之前又做了split。造成有些延遲離線的父region存在於META表和HDFS中,但是沒有部署,HBASE又不能清除他們。這種情況下可以使用此命令重置這些在META表中的region為在線狀態並且沒有split。然後就可以使用之前的修復命令把這個region修復

1.1 手動merge region

進行操作前先將balancer關閉,操作完成後再打開balancer

經過一段時間的運行之後有可能會產生一些很小的region,

需要定期檢查這些region並將它們和相鄰的region合並以減少系統的總region數,減少管理開銷

合並方法:

  1. 找到需要合並的region的encoded name
  2. 進入hbase shell
  3. 執行merge_region ‘region1’,’region2’

1.1 手動分配region

如果發現臺regionServer資源占用特別高,可以檢查這臺regionserver上的region是否存在過多比較大的region,通過hbase shell將部分比較大的region分配給其他不是很忙的regions server:

move ‘regionId’,’serverName’

例:

move ‘54fca23d09a595bd3496cd0c9d6cae85‘,‘vmcnod05,60020,1390211132297‘

1.1 手動major_compact

進行操作前先將balancer關閉,操作完成後再打開balancer

選擇一個系統比較空閑的時間手工major_compact,如果hbase更新不是太頻繁,可以一個星期對所有表做一次 major_compact,這個可以在做完一次major_compact後,觀看所有的storefile數量,如果storefile數量增加到 major_compact後的storefile的近二倍時,可以對所有表做一次major_compact,時間比較長,操作盡量避免高鋒期

註:fms現在生產上開啟了自動major_compact,不需要做手動major compact

1.1 balance_switch

balance_switch true 打開balancer

balance_switch flase 關閉balancer

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

1.1 regionserver重啟

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.1 regionserver關閉下線

bin/graceful_stop.sh nodename

進行操作前先將balancer關閉,操作完成後再打開balancer

和上面一樣,系統會在關閉之前遷移所有region,然後stop進程。

1.1 flush

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

1.2 Hbase遷移

1.2.1 copytable方式

bin/hbase org.apache.hadoop.hbase.mapreduce.CopyTable --peer.adr=zookeeper1,zookeeper2,zookeeper3:/hbase ‘testtable‘

這個操作需要添加hbase目錄裏的conf/mapred-site.xml,可以復制hadoop的過來。

1.1.1 Export/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.1.2 直接拷貝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

1 Hadoop日常運維

1.1 監控Hadoop運行狀況

  1. nameNode、ResourseManager內存(namenode要有足夠內存)
  2. DataNode和NodeManager運行狀態
  3. 磁盤使用情況
  4. 服務器負載狀態

1.2 檢查HDFS文件健康狀況

命令:hadoop fsck

1.1 開啟垃圾箱(trash)功能

trash功能它默認是關閉的,開啟後,被你刪除的數據將會mv到操作用戶目錄的".Trash"文件夾,可以配置超過多長時間,系統自動刪除過期數據。這樣一來,當操作失誤的時候,可以把數據mv回來

2 本項目場景下的hbase參數調整

技術分享

Hbase運維參考(項目)