作者：朱超杰

故障描述

1.1發(fā)生背景

很久很久以前，有一天，我在HBase中新建了一張表 “XXX: XXX _EXCEPTION_LIST_INFO”，同時(shí)HBase在處理大量更新操作。然后在DROP掉表XXX: XXX_EXCEPTION_LIST_INFO時(shí)，HBase Master就宕機(jī)。

之后通過CM重新啟動(dòng)后HBase服務(wù)，服務(wù)重啟后發(fā)生如下兩個(gè)錯(cuò)誤，導(dǎo)致HBase集群無法正常恢復(fù)：(1)HMaster節(jié)點(diǎn)自動(dòng)Active失敗；(2)大量Region出現(xiàn)offline和RIT。

1.2現(xiàn)象描述

HA HMaster節(jié)點(diǎn)啟動(dòng)了，過一段時(shí)間Active HBase Master節(jié)點(diǎn)自動(dòng)失敗(大概3~5分鐘)。因?yàn)榧翰捎昧薍A高可用，因此Standby HBase Master節(jié)點(diǎn)自動(dòng)切換為Active。再過差不多相同時(shí)間，該節(jié)點(diǎn)也自動(dòng)失敗。

查看Master節(jié)點(diǎn)的日志報(bào)錯(cuò)如下

Failed to become active master java.io.IOException: Timedout 300000ms waiting for namespace table to be assigned

Master Web UI上顯示處于RIT的Region

Master狀態(tài)頁(yè)告警信息：

Found regions staying in transition state for a duration longer than the configured threshold in HBase.

故障分析處理

1.Master的日志報(bào)錯(cuò)：Timeout 300000ms waiting for namespace table to be assigned.表示namespace表未分配，并且超過設(shè)置的時(shí)間閾值。在HBase的設(shè)計(jì)中，Master啟動(dòng)時(shí)首先分配meta表，然后再分配其它表。系統(tǒng)表hbase:namespace和其它用戶表分配時(shí)同等對(duì)待，并沒有先分配系統(tǒng)表再分配用戶表，如果一個(gè)集群region非常多，默認(rèn)300000ms(5分鐘)還分配不到namespace表，此時(shí)需要修改hbase.master.namespace.init.timeout超時(shí)時(shí)間。

2.根據(jù)此時(shí)情況，通過CM在“hbase-site.xml的HBase服務(wù)高級(jí)配置代碼段(安全閥)”中增加以下配置：

<property>
<name>hbase.master.namespace.init.timeoutname>
<value>86400000value>
property>
<property>
<name>hbase.master.initializationmonitor.timeoutname>
<value>86400000value>
property>

即增加namespace表分配超時(shí)時(shí)間為1天。

修改完成之后重啟HBase服務(wù)，這里選擇滾動(dòng)重啟HBase時(shí)RegionServer無法重啟，所以選擇完成重啟HBase服務(wù)。

3.重啟完成后，Master依然告警：Found regions staying in transition state for a duration longer than the configured threshold in HBase.，但服務(wù)并未宕掉，Master告警提示的原因是在HBase Master啟動(dòng)時(shí)，檢測(cè)到有Region長(zhǎng)時(shí)間處于RIT狀態(tài)(超過閾值)。

查看Master日志如下

大量Region處于PENDING_OPEN狀態(tài)，Master檢測(cè)到RIT，

查看Zookeeper中的/hbase/region-in-transition，也可以看到大量的Region。

說明：每次HBase Master對(duì)Region的一個(gè)OPEN或一個(gè)CLOSE操作都會(huì)向Master 的RIT列表中插入一條記錄，因?yàn)镸aster對(duì)Region的操作要保持原子性。Region的 OPEN和 CLOSE是通過HBase Master和 RegionServer 協(xié)助來完成的。為了滿足這些操作的協(xié)調(diào)、回滾、一致性，HBase Master采用了 RIT 機(jī)制并結(jié)合Zookeeper 中znode狀態(tài)來保證操作的安全和一致性。

Region有以下幾種狀態(tài)：

• OFFLINE：region is in an offline state

• PENDING_OPEN：sent rpc to server to open but has not begun

• OPENING：server has begun to open but not yet done

• OPEN：server opened region and updated meta

• PENDING_CLOSE：sent rpc to server to close but has not begun

• CLOSING：server has begun to close but not yet done

• CLOSED：server closed region and updated meta

• SPLITTING：server started split of a region

• SPLIT：server completed split of a region

在注冊(cè)為active的Master Web UI上查看已上線的Region數(shù)如下：

4.經(jīng)確認(rèn)HBase未使用replication后，選擇重建Znode的方式進(jìn)行測(cè)試：

?a.停止HBase服務(wù)

?b.使用hbase zkcli命令進(jìn)入ZK客戶端

?c.執(zhí)行rmr /hbase清除/hbase

d.重啟HBase服務(wù)，此時(shí)/hbase會(huì)重新生成

5.但是重啟完之后問題依然存在，再次查看Master日志發(fā)現(xiàn)如下信息：

6.查看RegionServer的日志，可以看到頻繁出現(xiàn)以下錯(cuò)誤：

由上可以看出索引表的Region is not online，查看RegionServer Web UI發(fā)現(xiàn)RPC線程一直處于Initializing Region的Replaying edits階段，并且在等待一個(gè)小時(shí)時(shí)間后依然未完成。因此分析原因?yàn)镻hoenix索引表的Region不能online，導(dǎo)致數(shù)據(jù)表的Region構(gòu)建進(jìn)程卡住，但是這些構(gòu)建進(jìn)程占用了openregion線程(默認(rèn)3個(gè))，導(dǎo)致索引表不能正常openregion，產(chǎn)生死鎖。

因此需要調(diào)整hbase.regionserver.executor.openregion.threads參數(shù)以增加openregion線程數(shù)。

7.通過CM在“hbase-site.xml的HBase服務(wù)高級(jí)配置代碼段(安全閥)”中增加以下配置：

<property>
<name>hbase.regionserver.executor.openregion.threadsname>
<value>200value>
property>

即增加Region分配線程數(shù)至200個(gè)，然后再次重啟HBase服務(wù)

重啟HBase服務(wù)， HBase Master仍有告警信息，但在Active Master Web UI上可以看到上線的Region數(shù)量在增加，同時(shí)RIT中的Region數(shù)量在減少。稍等片刻后HBase服務(wù)恢復(fù)正常。

經(jīng)測(cè)試HBase可以正常提供服務(wù)，數(shù)據(jù)無丟失。

處理結(jié)論

1.HBase Master在啟動(dòng)時(shí)會(huì)首先分配meta表的Region，然后再分配其它表。namespace表和user表分配時(shí)同等對(duì)待，并沒有先分配系統(tǒng)表再分配用戶表，如果一個(gè)集群Region非常多，默認(rèn)300000ms(5分鐘)有可能還分配不到namespace表，此時(shí)拋出異常：Failed to become active master java.io.IOException: Timedout 300000ms waiting for namespace table to be assigned。此時(shí)需要調(diào)整參數(shù)hbase.master.namespace.init.timeout增加超時(shí)時(shí)間。

2.分布式死鎖發(fā)生在使用Phoenix(4.14.1)構(gòu)建二級(jí)索引，并且數(shù)據(jù)表、二級(jí)索引表的Region數(shù)量適中的集群中。當(dāng)RegionServer打開Phoenix數(shù)據(jù)表的一個(gè)Region時(shí)，它將為該Region執(zhí)行WAL重播，并重新構(gòu)建二級(jí)索引表，而數(shù)據(jù)表的Region分配依賴于二級(jí)索引表。默認(rèn)情況下每個(gè)RS上只有一個(gè)線程池，包含三個(gè)openregion線程。而二級(jí)索引表和數(shù)據(jù)表共用同一個(gè)線程池。因此，當(dāng)Phoenix數(shù)據(jù)表的Region的這些重建進(jìn)程占用了openregion線程時(shí)，二級(jí)索引表就只能進(jìn)入隊(duì)列等候，其Region就不能online。這就是死鎖發(fā)生的原因。

解決方式可以在hbase-site.xml中修改以下參數(shù)：

1)設(shè)置hbase.master.startup.retainassign為false(默認(rèn)為true)

2)增加hbase.regionserver.executor.openregion.threads 的值(默認(rèn)為3)，然后重啟集群解決。

如果還是出現(xiàn)同樣問題，可以調(diào)優(yōu)以下分配管理器參數(shù)，以匹配Region的數(shù)量，從而加快分配速度：

• hbase.assignment.threads.max：線程池大小，默認(rèn)值30

• hbase.master.namespace.init.timeout：默認(rèn)值300000ms

• hbase.master.wait.on.regionservers.mintostart：向HMaster匯報(bào)的RegionServer的數(shù)量最小啟動(dòng)值，默認(rèn)值1

• hbase.bulk.assignment.threshold.regions：Region數(shù)量超過閾值(默認(rèn)值7)，使用bulk assign

• hbase.bulk.assignment.threshold.servers ：Server數(shù)量超過閾值(默認(rèn)值3)，使用bulk assign

參考鏈接：

https://issues.apache.org/jira/browse/PHOENIX-3072

https://issues.apache.org/jira/browse/HBASE-16095

https://docs.cloudera.com/documentation/enterprise/release-notes/topics/cdh_rn_phoenix_ki.html#concept_xdx_1wq_dq

總結(jié)

以上是生活随笔為你收集整理的resultset rs =pst.executequery();发生异常_07795.14.4HMaster无法成为Active异常分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。