問題起源
?這個問題的起因歸咎于最近Y集群上的一張表A在對外提供數(shù)據(jù)服務(wù)的時候突然時不時大量拋超時異常臭挽，當(dāng)時重啟Region Server暫時停止拋超時異常约郁，但是問題沒有根本解決因為此種情況依舊繼續(xù)不斷復(fù)現(xiàn)庭瑰。
?首先對X集群上的HBase表A做一次Major Compaction(Y集群的表由X集群上的表每天加工完成之后復(fù)制到Y(jié)集群上，由于Y集群對外提供查詢服務(wù)蜕该，為保證服務(wù)穩(wěn)定因此修復(fù)表的操作都在X集群上進(jìn)行）栓拜，然后過了一段時間后，在HBase WebUI上查看這張表的大合并是已結(jié)束的呀邢，但是這張表有兩個Rgion的Locality還是很低洒沦，于是懷疑兩個Region大合沒有真正的成功。
?接著查找兩個Region所在的Region Server日志發(fā)現(xiàn)能夠看到兩個Region的start compacting記錄但是無法找到region compaction completed記錄价淌。在Region Server WebUI上發(fā)現(xiàn)兩個Region處于Closing狀態(tài)申眼，具體為disabling compacting and flushes for region并且此種狀態(tài)持續(xù)很久，單獨對兩個Region做大合并仍舊出現(xiàn)同樣現(xiàn)象蝉衣。過段時間兩個region就會處于RIT狀態(tài)括尸。總而言之,兩個Region的Major&Minor Compaction無法結(jié)束病毡。
嘗試解決
assign兩個Region(失敗濒翻，具體現(xiàn)象為很快相關(guān)Region又會處于RIT狀態(tài))
move這兩個Region到新的Region Server(失敗，現(xiàn)象同上)
重啟兩個Region所在的Region Server(失敗啦膜，現(xiàn)象同上)
-
對這張表做快照有送，隨后clone一張新表出來，對這張表做major_compact(失敗僧家，現(xiàn)象同上雀摘，另外還遇到disable表不成功的現(xiàn)象，如下圖所示通過重啟Region Server解決)
image 寫程序八拱，將這張表的數(shù)據(jù)讀出來阵赠，寫進(jìn)一張新表上(失敗，在讀到問題Region 的數(shù)據(jù)時肌稻，會報超時異常清蚀，修改超時時間為1h，依然報超時)
drop掉這張表爹谭，重新建表枷邪，重新加工了一遍存量(成功)
定位原因
?這張表的Data Block Encoding為prefix tree。如果是這種編碼方式就會存在Compaction無法結(jié)束的風(fēng)險旦棉。
解決辦法
?將表drop掉齿风，這個時候hbck一下已經(jīng)被drop掉的表，可能會發(fā)現(xiàn)那兩個region還會存在異常绑洛，然后重啟下這兩個region 對應(yīng)的region server救斑。隨后將這張表重新加工一份，就可以了真屯。
- disable ‘A’脸候；
- drop ‘A’；
- hbase hbck -details 'A' 這時候會發(fā)現(xiàn)還能夠檢測出來A表的不一致。我們這里的猜測是运沦，關(guān)于A表的region 信息還會存在在Region Server的內(nèi)存里泵额，并沒有隨著drop操作而刪除干凈；
- 重啟問題Region 所在的Region Server携添；
- hbase hbck -details 'A' 這個時候檢測的結(jié)果嫁盲，這張表才是顯示正常的，證明此刻這張表刪除干凈烈掠；
- 重新建表羞秤，指定data block encoding = 'NONE'，并重新跑程序進(jìn)行數(shù)據(jù)重新加工左敌；
- hbase hbck -details 'A' 這個時候結(jié)果顯示才是沒問題瘾蛋，至此問題搞定。
排查總結(jié)
?drop掉之后矫限，如果不重啟Region Server可能會存在drop表不干凈的問題哺哼，兩個Region的信息駐留在Region Server對應(yīng)的內(nèi)存里面，此時如果重新加工一個同樣名字的表那這張新表可能存在此類問題叼风，比如online的時候創(chuàng)建快照建不成功或者offline的時候雖然快照可以創(chuàng)建成功取董，但是極有可能會把未刪干凈的Region信息給帶到snapshot里。另外就是關(guān)于跨集群復(fù)制无宿，如果在源端集群表的個別region 有問題甲葬，在數(shù)據(jù)通過快照的方式復(fù)制到目標(biāo)集群后，目標(biāo)端對應(yīng)的個別region 也會出現(xiàn)一模一樣的問題懈贺。其實我們公司內(nèi)部的hbase表從X集群復(fù)制到Y(jié)集群是通過快照的方式進(jìn)行：
- X集群上的表A進(jìn)行數(shù)據(jù)加工
- X集群上對表A，建快照：snapshot ‘A’ ‘snapshotA’
- Y集群上將A集群的快照復(fù)制過來：hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot ***
- Y集群disable 'A'
- Y集群restore ‘snapshotA’
- Y集群enable ‘A’
?通過以上方式把加工出來的表跨集群復(fù)制到另外一個集群供應(yīng)用系統(tǒng)查詢從而做到讀寫分離坡垫，但是由于在Y集群存在對表的disable操作梭灿，因此該表對于應(yīng)用而言會存在短暫不可用的現(xiàn)象。目前針對于讀寫分離場景怎樣避免這個短暫不可用還一直未找到非常好的解決方案冰悠，如果大家有好的建議或者方案發(fā)布到HBase技術(shù)社區(qū)論壇http://hbase.group
更多技術(shù)交流堡妒，可關(guān)注微信交流群，微信公眾號等：
或參考文章： HBase中文社區(qū)官網(wǎng)溉卓、交流群
1. 微信群
2. 釘釘群：
3. 微信公眾號：
