Hbase運維手冊1.region情況需要檢查1. region的數量（總數和每臺regionserver上的region數）2. region的大小如果發現異常可以通過手動merge region和手動分配region來調整從CDH前臺和master前臺以及regionServer的前臺都可以看到region數量，如master前臺： 在region server前臺可以看到storeFile大小：2.緩存命中率緩存命中率對hbase的讀有很大的影響，可以觀察這個指標來調整blockcache的大小。從regionserver web頁面可以看到block cache的情況： 注意：HBase上Regionserver的內存分為兩個部分，一部分作為Memstore，主要用來寫；另外一部分作為BlockCache，主要用于讀。 寫請求會先寫入Memstore，Regionserver會給每個region提供列族數提供一定數量的Memstore，當Memstore滿64MB以后，會啟動 flush刷新到磁盤。當Memstore的總大小超過限制時（heapsize * hbase.regionserver.global.memstore.upperLimit * 0.9），會強行啟動flush進程，從最大的Memstore開始flush直到低于限制。 讀請求先到Memstore中查數據，查不到就到BlockCache中查，再查不到就會到磁盤上讀，并把讀的結果放入BlockCache。由于BlockCache采用的是LRU策略，因此BlockCache達到上限(heapsize * hfile.block.cache.size * 0.85)后，會啟動淘汰機制，淘汰掉最老的一批數據。一個Regionserver上有一個BlockCache和N個Memstore，它們的大小之和不能大于等于heapsize * 0.8，否則HBase不能正常啟動。默認配置下，BlockCache為0.2，而Memstore為0.4。在注重讀響應時間的應用場景下，可以將 BlockCache設置大些，Memstore設置小些，以加大緩存的命中率。HBase RegionServer包含三個級別的Block優先級隊列： Single：如果一個Block第一次被訪問，則放在這一優先級隊列中； Multi：如果一個Block被多次訪問，則從Single隊列移到Multi隊列中； InMemory：如果一個Block是inMemory的，則放到這個隊列中。以上將Cache分級思想的好處在于： 首先，通過inMemory類型Cache，可以有選擇地將in-memory的column families放到RegionServer內存中，例如Meta元數據信息； 通過區分Single和Multi類型Cache，可以防止由于Scan操作帶來的Cache頻繁顛簸，將最少使用的Block加入到淘汰算法中。默認配置下，對于整個BlockCache的內存，又按照以下百分比分配給Single、Multi、InMemory使用：0.25、0.50和0.25。注意，其中InMemory隊列用于保存HBase Meta表元數據信息，因此如果將數據量很大的用戶表設置為InMemory的話，可能會導致Meta表緩存失效，進而對整個集群的性能產生影響。3.讀寫請求數通過讀寫請求數可以大概看出每臺regionServer的壓力，如果壓力分布不均勻，應該檢查regionServer上的region以及其它指標 4.壓縮隊列壓縮隊列存放的是正在壓縮的storefile，compact操作對hbase的讀寫影響較大通過cdh的hbase圖表庫可以看到集群總的壓縮隊列大小：可以通過CDH的hbase主頁查詢compact日志：點擊“壓縮”進入：5.刷新隊列單個region的memstore寫滿(128M)或regionServer上所有region的memstore大小總合達到門限時會進行flush操作,flush操作會產生新的storeFile同樣可以通過CDH的hbase前臺查看flush日志：6.rpc調用隊列沒有及時處理的rpc操作會放入rpc操作隊列，從rpc隊列可以看出服務器處理請求的情況 7.文件塊保存在本地的百分比datanode和regionserver一般都部署在同一臺機器上，所以region server管理的region會優先存儲在本地，以節省網絡開銷。如果block locality較低有可能是剛做過balance或剛重啟，經過compact之后region的數據都會寫到當前機器的datanode，block locality也會慢慢達到接近100：8.內存使用情況內存使用情況,主要可以看used Heap和memstore的大小，如果usedHeadp一直超過80-85%以上是比較危險的memstore很小或很大也不正常從region Server的前臺可以看到： 9.檢查數據一致性以及修復方法數據一致性是指：1. 每個region都被正確的分配到一臺regionserver上，并且region的位置信息及狀態都是正確的。2. 每個table都是完整的，每一個可能的rowkey都可以對應到唯一的一個regionhbase hbck注：有時集群正在啟動或region正在做split操作，會造成數據不一致hbase hbck -details加上details會列出更詳細的檢查信息，包括所以正在進行的split任務hbase hbck Table1 Table2如果只想檢查指定的表，可以在命令后面加上表名，這樣可以節省操作時間CDH通過CDH提供的檢查報告也可以看到hbck的結果，日常只需要看CDH hbck的報告即可： 選擇“最近的Hbck結果”： 1)局部的修復如果出現數據不一致，修復時要最大限度的降低可能出現的風險，使用以下命令對region進行修復風險較低： hbase hbck -fixAssignments 修復region沒有分配(unassigned)，錯誤分配（incorrectly assigned）以及多次分配（multiply assigned）的問題 hbase hbck -fixMeta 刪除META表里有記錄但HDFS里沒有數據記錄的region 添加HDFS里有數據但是META表里沒有記錄的region到META表 hbase hbck -repairHoles 等價于：hbase hbck -fixAssignments -fixMeta -fixHdfsHoles -fixHdfsHoles的作用： 如果rowkey出現空洞，即相鄰的兩個region的rowkey不連續，則使用這個參數會在HDFS里面創建一個新的region。創建新的region之后要使用-fixMeta和-fixAssignments參數來使用掛載這個region，所以一般和前兩個參數一起使用 2）Region重疊修復 進行以下操作非常危險，因為這些操作會修改文件系統，需要謹慎操作！ 進行以下操作前先使用hbck details查看詳細問題，如果需要進行修復先停掉應用，如果執行以下命令時同時有數據操作可能會造成不可期的異常。 hbase hbck -fixHdfsOrphans 將文件系統中的沒有metadata文件(.regioninfo)的region目錄加入到hbase中，即創建.regioninfo目錄并將region分配到regionser hbase 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 . hbase hbck -repair 以下命令的縮寫：hba hbase hbck -fixAssignments -fixMeta -fixHdfsHoles -fixHdfsOrphans -fixHdfsOverlaps -fixVersionFile sidelineBigOverlaps 可以指定表名：hba hbase hbck -repair Table1 Table2 hbase hbck -fixMetaOnly fixAssignments 如果只有META表的region不一致，則可以使用這個命令修復 hbase hbck fixVersionFile Hbase的數據文件啟動時需要一個version file，如果這個文件丟失，可以用這個命令來新建一個，但是要保證hbck的版本和Hbase集群的版本是一樣的 hbase org.apache.hadoop.hbase.util.hbck.OfflineMetaRepair 如果ROOT表和META表都出問題了Hbase無法啟動，可以用這個命令來創建新的ROOT和META表。 這個命令的前提是Hbase已經關閉，執行時它會從hbase的home目錄加載hbase的相關信息（.regioninfo），如果表的信息是完整的就會創建新的root和meta目錄及數據 hbase hbck fixSplitParents 當region做split操作的時候，父region會被自動清除掉。但是有時候子region在父region被清除之前又做了split。造成有些延遲離線的父region存在于META表和HDFS中，但是沒有部署，HBASE又不能清除他們。這種情況下可以 使用此命令重置這些在META表中的region為在線狀態并且沒有split。然后就可以使用之前的修復命令把這個region修復 10.手動merge region進行操作前先將balancer關閉，操作完成后再打開balancer經過一段時間的運行之后有可能會產生一些很小的region，需要定期檢查這些region并將它們和相鄰的region合并以減少系統的總region數，減少管理開銷 合并方法：1. 找到需要合并的region的encoded name2. 進入hbase shell3. 執行merge_region region1,region2 手動分配region如果發現臺regionServer資源占用特別高，可以檢查這臺regionserver上的region是否存在過多比較大的region,通過hbase shell將部分比較大的region分配給其他不是很忙的regions server：move encodeRegionName, ServerName #encodeRegionName指的regioName后面的編碼，ServerName指的是master-status的Region Servers列表例：move 24d9eef6ba5616b1a60180503e62bae7,DN1,60020,1429840460046手動major_compact進行操作前先將balancer關閉，操作完成后再打開balancer選擇一個系統比較空閑的時間手工major_compact，如果hbase更新不是太頻繁，可以一個星期對所有表做一次 major_compact，這個可以在做完一次major_compact后，觀看所有的storefile數量，如果storefile數量增加到 major_compact后的storefile的近二倍時，可以對所有表做一次major_compact，時間比較長，操作盡量避免高鋒期注：fms現在生產上開啟了自動major_compact，不需要做手動major compactbalance_switchbalance_switch true 打開balancerbalance_switch flase 關閉balancer配置master是否執行平衡各個regionserver的region數量，當我們需要維護或者重啟一個regionserver時，會關閉balancer，這樣就使得region在regionserver上的分布不均，這個時候需要手工的開啟balance。regionserver重啟 graceful_stop.sh -restart -reload -debugnodename進行操作前先將balancer關閉，操作完成后再打開balancer這個操作是平滑的重啟regionserver進程，對服務不會有影響，他會先將需要重啟的regionserver上面的所有region遷移到其它的服務器，然后重啟，最后又會將之前的region遷移回來，但我們修改一個配置時，可以用這種方式重啟每一臺機 子，對于hbase regionserver重啟，不要直接kill進程，這樣會造成在zookeeper.session.timeout這個時間長的中斷，也不要通過bin/hbase-daemon.sh stop regionserver去重啟，如果運氣不太好，-ROOT-或者.META.表在上面的話，所有的 請求會全部失敗regionserver關閉下線bin/graceful_stop.sh nodename進行操作前先將balancer關閉，操作完成后再打開balancer和上面一樣，系統會在關閉之前遷移所有region，然后stop進程。flush表所有memstore刷新到hdfs，通常如果發現regionserver的內存使用過大，造成該機的 regionserver很多線程block，可以執行一下flush操作，這個操作會造成hbase的storefile數量劇增，應盡量避免這個操 作，還有一種情況，在hbase進行遷移的時候，如果選擇拷貝文件方式，可以先停寫入，然后flush所有表，拷貝文件強制splitHbase 允許客戶端強制執行split,在hbase shell中執行以下命令： split forced_table, b /其中forced_table 為要split的table , b 為split 點region splits執行過程：region server處理寫請求的時候，會先寫入memstore，當memstore 達到一定大小的時候，會寫入磁盤成為一個store file。這個過程叫做 memstore flush。當store files 堆積到一定大小的時候，region server 會 執行compact操作，把他們合成一個大的文件。 當每次執行完flush 或者compact操作，都會判斷是否需要split。當發生split的時候，會生成兩個region A 和 region B但是parent region數據file并不會發生復制等操作，而是region A 和region B 會有這些file的引用。這些引用文件會在下次發生compact操作的時候清理掉，并且當region中有引用文件的時候是不會再進行split操作的。這個地方需要注意一下:(大量的寫入會刷大量的HFile，一個region就會對這大量的hfile進行compact操作。如果這時候觸發了split操作，這個region會成為父region，而兩個子region會保留父region的引用文件。而在這其間，子region會繼續寫入數據。那么又可能觸發子region的compact，這里的關鍵點來了子region如果做compact的文件都是新寫入的文件，而遲遲不去compact父region 引用的文件，會導致一個問題就是這個子region無法被split掉了（因為含有父region引用的region是不能被split的）。那么子region越來越大，由于寫入文件數量急劇增長，父region的ref文件總也得不到機會compact，就形成了大region的惡性循環情況由于region太大，compact無法完成，但是由于compact無法完成導致region無法split，無法分攤compact的壓力給其他regionserver。)雖然split region操作是region server單獨確定的，但是split過程必須和很多其他部件合作。region server 在split開始前和結束前通知master,并且需要更新.META.表，這樣，客戶端就能知道有新的region。在hdfs中重新排列目錄結構和數據文件。split是一個復雜的操作。在split region的時候會記錄當前執行的狀態，當出錯的時候，會根據狀態進行回滾。下圖表示split中，執行的過程。（紅色線表示region server 或者master的操作，綠色線表示client的操作。）1.region server 決定split region，第一步，region server在zookeeper中創建在/hbase/region-in-transition/region-name 目錄下，創建一個znode，狀態為SPLITTING.2.因為master有對region-in-transition 的znode做監聽，所以，mater的得知parent region需要split3.region server 在hdfs的parent region的目錄下創建一個名為“.splits”的子目錄4.region server 關閉parent region。強制flush緩存，并且在本地數據結構中標記region為下線狀態。如果這個時候客戶端剛好請求到parent region，會拋出NotServingRegionException。這時客戶端會進行補償性重試。5.region server在.split 目錄下分別為兩個daughter region創建目錄和必要的數據結構。然后創建兩個引用文件指向parent regions的文件。6.region server 在HDFS中，創建真正的region目錄，并且把引用文件移到對應的目錄下。7.region server 發送一個put的請求到.META.表中，并且在.META.表中設置parent region為下線狀態，并且在parent region對應的row中兩個daughter region的信息。但是這個時候在.META.表中daughter region 還不是獨立的row。這個時候如果client scan .META.表，會發現parent region正在split，但是client還看不到daughter region的信息。當這個put 成功之后，parent region split會被正在的執行。如果在 RPC 成功之前 region server 就失敗了，master和下次打開parent region的region server 會清除關于這次split的臟狀態。但是當RPC返回結果給到parent region ，即.META.成功更新之后，region split的流程還會繼續進行下去。相當于是個補償機制，下次在打開這個parent region的時候會進行相應的清理操作。8.region server 打開兩個daughter region接受寫操作。9.region server 在.META.表中增加daughters A 和 B region的相關信息，在這以后，client就能發現這兩個新的regions并且能發送請求到這兩個新的region了。client本地具體有.META.表的緩存，當他們訪問到parent region的時候，發現parent region下線了，就會重新訪問.META.表獲取最新的信息，并且更新本地緩存。10.region server 更新