hbase2.0處理rit狀態記錄web
日期shell |
版本號apache |
類別微信 |
描述 |
2019-07-05app |
1.0.0高併發 |
A工具 |
排查hbase2.0的rit問題oop |
問題說明學習
因爲使用HDP3.0，HDP3.0使用的是hbase2.0.0版本，hbase的ui頁面發現不少表出現了rit，刪除表過程當中，region的狀態卡在了opening。先嚐試使用hbck2工具進行修復，發如今hbase2.0的master的rpc方法中沒有hbck2中的bypass，assign方法，經過源碼發現，hbck2的rpc方法是在hbase2.0.2中才增長的，因此只能嘗試手動處理：
一.hdfs上已經沒有對應目錄，meta裏沒有對應表狀態信息，存在有對應的分區信息
1. 檢查表狀態
get 'hbase:meta','KYLIN_0054K9NLSU','table:state'
結果爲空
2. 經過源碼發現表狀態
ENABLED,對應meta表裏的值\x80\x00
DISABLED, 對應meta表裏的值\x80\x01
DISABLING, 對應meta表裏的值\x80\x02
ENABLING, 對應meta表裏的值\x80\x03
3. 查找分區信息
scan 'hbase:meta',{FILTER => org.apache.hadoop.hbase.filter.PrefixFilter.new(org.apache.hadoop.hbase.util.Bytes.toBytes('KYLIN_0054K9NLSU'))}
發現存在有分區記錄
4. 手動修改表狀態或者刪除分區信息
put 'hbase:meta','KYLIN_0054K9NLSU','table:state','\x80\x01'
或者deleteall 表對應的分區信息，修改後重啓hbase，發現rit狀態消失
二.hdfs上已經有對應目錄，meta裏有對應表狀態信息和分區信息
1. 確認一下表的信息和數據
hbase hbck -summary TableName
2. 檢查表狀態
get 'hbase:meta','KYLIN_0354K9NLSU','table:state'
meta表裏的值\x80\x02，表的狀態爲DISABLING
3. 找出異常的region
echo "scan 'hbase:meta',{FILTER => org.apache.hadoop.hbase.filter.PrefixFilter.new(org.apache.hadoop.hbase.util.Bytes.toBytes('KYLIN_0354K9NLSU'))}"|hbase shell -n|grep OPENING
找出異常的region
4. 將region信息更新爲CLOSED狀態
put 'hbase:meta','KYLIN_0354K9NLSU,,1561953520536.30b7d24eaa3209c6e5e8de764ad04855.','info:state','CLOSED',1562117738678
………
5. 將表狀態更新爲disable
put 'hbase:meta','KYLIN_0354K9NLSU','table:state',"\x08\x01",1562120793251
重啓hbase後rit消失
存在問題
rit是刪除表的時候出現，因此表中的數據能夠忽略，上述操做也是表中沒有數據時操做
若是是生成集羣，已經存在的數據比較多，不建議直接重啓，能夠經過切換master的方式
可使用HDP3.1.1，裏面hbase版本是2.0.2，可使用hbck2操做
使用hbck2的方法的話，修改meta狀態後還會同步改zookeeper狀態，能避免狀態不一致
HBase2.x之RIT問題解決
問題描述
Region-In-Trasition機制：從字面意思來看，Region-In-Transition說的是Region變遷機制，其實是指在一次特定操做行爲中Region狀態的變遷，例如merge、split、assign、unssign等操做。RIT問題指的是在RIT過程當中出現異常狀況，而後致使region的狀態一直保持在RIT，使得HBase出現異常。
解決方案
方案一
檢查hdfs的健康度，是否有hbase的文件丟失或損壞，運行命令hadoop fsck /，結果以下：
排除hdfs丟失block的問題。若是出現hdfs的block損壞或丟失的狀況，能夠經過hdfs的修復命令進行修復。
方案二
在HBase1.x系列中RIT問題一般能夠經過hbase hbck –repair操做完成修復。可是在HBase2.x系列中，該命令尚未支持，因此暫時沒法經過這種命令完成修復。結果以下：
第一次執行發現沒有權限，root用戶不是hdfs的超級用戶，安裝提示須要以hbase用戶去執行該命令。修改以下：
su hbase -s /bin/sh -c "hbase hbck -repair"
提示爲hbase有其餘線程正在執行hbck fix命令，可是其實沒有這種命令，其實從這裏就能夠看出HBase2.x對於-repair的支持是不夠的。我按照提示刪除了hdfs(/hbase/.tmp/)上的hbase-hbck.lock文件，從新運行命令以下：
方案三
根據RIT狀態執行assign或者unassign命令，狀態信息以下：
通過查詢資料，解決方案以下：
hbase shell屢次執行unassign '20acfcbd68fd624a78bb34c88f9382d1'和unassign '20acfcbd68fd624a78bb34c88f9382d1' , true都超時結束，經過修改rpc和zk的超時時間都沒法完成(正常超時時間爲60000ms，修改成600000ms)。
方案四
通過屢次試驗，最終都沒法使得HBase回覆正常，最終決定刪除進行測試。
Zookeeper節點刪除：
經過hbase zkcli命令進入Zookeeper命令行界面：
我想刪除節點 /hbase-unsecure/region-in-transition，可是發現並無該節點，通過資料查詢瞭解到HBase2.x的RIT狀態並不像HBase1.x系列存儲在Zookeeper上。通過測試刪除/hbase節點重啓hbase並不能解決RIT問題。
HBase表刪除：
hbase shell>disable M_TDY_PT_LCZZ
disable失敗，因此正常刪除表操做沒法執行。須要進行暴力刪除，暴力刪除指的是從元數據進行刪除。
先停掉HBase
刪除hdfs表目錄(記得先備份，等下恢復用)
hdfs dfs -cp /hbase/data/hospital/P_TDY_DASC_DE02_01_039_63 /
hdfs dfs -cp /hbase/data/hospital/M_TDY_PT_LCZZ /
hdfs dfs -rm -r -skipTrash /hbase/data/hospital/P_TDY_DASC_DE02_01_039_63
hdfs dfs -rm -r -skipTrash /hbase/data/hospital/ M_TDY_PT_LCZZ
delete 'hbase:meta','rowkey', 'column'
Rowkey信息能夠經過hbase的UI看到：
而後重啓HBase，可是發現問題沒有解決。
hbase shell查詢數據看到hbase的meta刪除失敗了，本來的meta信息還在：
而後從新刪除(delete命令換成deleteall命令)：
再刪除Zookeeper中的/hbase節點，重啓HBase發現RIT問題已經解決了。
後續就是重建表，而後恢復數據。
Phoenix故障處理筆記
1. Timeline
06-26 16:00 Phoenix使用方反饋慢；
06-26 16:02 同事經過監控看到Phoenix HBase集羣一個對應的RegionServer，QueueSize太高，此bug基本是Butch Put Lock在高併發寫入的問題，咱們已在下個版本中增長信息日誌定位此問題；
06-26 16:05 同事重啓該隊列太高的RegionServer；
06-26 16:10 同事跟我說，好多Phoenix的Region處於RIT狀態；
06-26 17:00 暫停該Phoenix集羣全部的寫入；
06-26 20:00 跟業務溝通，可能會正常影響一段時間，經贊成。至此各類hbck，各類重啓RegionServer&Master不怎麼管用，RIT數量升至550個；
06-27 12:00 嘗試修復；
06-27 15:00 問題修復。
2. 處理流程
2.1 異常現象
1. 大量Region沒法上線(NotServingRegionException)
2. Phoenix的SYSTEM.CATALOG系統表也沒法上線。
2.2 處理流程
手動assign SYSTEM.CATALOG 表的Region上線，而且跟蹤Master&對應RegionServer的日誌。整個offline&open流程都正常。可是中間會因爲各類其餘的表不在線failover後close掉；
打印jstack, 感受這幾個線程有問題，都在waiting；
經過上面的信息看，open region確實有問題。查看Phoenix Indexer Observer源碼就會知道是在根據Recover WAL Entry構建索引；
修改hbase.regionserver.executor.openregion.threads數,此配置是負責open region的handler數：
<property>
<name>hbase.regionserver.executor.openregion.threads</name>
<value>50</value>
</property>默認 3， 咱們這邊的hbase版本(1.0.0-cdh5.4.4)
重啓RegionServer；
assign SYSTEM.CATAOG 表的Region，上線成功；
修修補補，fixMeta fixAssignments就ok了。
3. 原理分析
1. 重啓RegionServer， 會形成該RegionServer上面的Region下線，而且被從新Balance到新的RegionServer中。
2. Region在新的RegionServer中open過程會找到該Region下的recover.edits 文件，進行replay；
3.Phoenix表使用HBase的協處理類型之Observer，具體使用查看示例
org.apache.phoenix.hbase.index.Indexer，此用做根據WAL構建索引的，具體參考Phoenix的相關材料。
4. 在SYSTEM.CATALOG 的打開過程當中，會查詢其餘的裏面表，其餘的表也處於RIT未恢復。然而其餘的表Region在open的過程也須要構建Index，尚且有一部分在openregion的隊列里面。最終SYSTEM.CATALOG沒法上線(此處不準確，純屬囫圇吞棗似的查看源碼推測)。
5. 增長open region handler數以後，重啓RegionServer後，須要進行一些hbck -fixMeta -fixAssginment 將一些未上線的Region上線, 就ok了。
6. 若是出現個別的Region仍是上線失敗，那就手動解決吧！我的認爲比hbck -repair暴力修復靠譜。
你們工做學習遇到HBase技術問題，把問題發佈到HBase技術社區論壇http://hbase.group，歡迎你們論壇上面提問留言討論。想了解更多HBase技術關注HBase技術社區公衆號(微信號:hbasegroup)，很是歡迎你們積極投稿。
本羣爲HBase+Spark技術交流討論，整合最優質的專家資源和技術資料會按期開展線下技術沙龍，專家技術直播，專家答疑活動
點擊連接釘釘入羣：
https://dwz.cn/Fvqv066s或掃碼進羣
本羣爲Cassandra技術交流討論，整合最優質的專家資源和技術資料會按期開展線下技術沙龍，專家技術直播，專家答疑活動
Cassandra 社區釘釘大羣：
https://c.tb.cn/F3.ZRTY0o
Cassandra 技術社區微信公衆號：
本文分享自微信公衆號 - ApacheHudi（ApacheHudi）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。