hbase問題總結

 

 1 java.io.IOException: java.io.IOException: java.lang.IllegalArgumentException: offset (0) + length (8) exceed the capacity of the array: 4

做簡單的incr操作時出現，原因是之前put時放入的是int  長度為 vlen=4 ，不適用增加操作，只能改為long型 vlen=8

 

2 寫資料到column時 org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 1 action: NotServingRegionException: 1 time, servers with issues: 10.xx.xx.37:60020,    或是 org.apache.hadoop.hbase.NotServingRegionException: Region is not online:   這兩種出錯，master-status中出現Regions in Transition 長達十幾分鐘，一直處於PENDING_OPEN狀態，導致請求阻塞。目前把10.xx.xx.37這台機器下線，運行一夜穩定，沒有出現因split造成的阻塞。懷疑是機器問題。Hmaster的日誌顯示這台region server 不停的open close，不做任何split 或flush

RIT 的全稱是region in transcation. 每次hbase master 對region 的一個open 或一個close 操作都會向Master 的RIT中插入一條記錄,因為master 對region 的操作要保持原子性,region 的 open 和 close 是通過Hmaster 和 region server 協助來完成的. 所以為了滿足這些操作的協調,復原,和一致性.Hmaster 採用了 RIT 機制並結合Zookeeper 中Node的狀態來保證操作的安全和一致性.

OFFLINE, // region is in an offline statePENDING_OPEN, // sent rpc to server to open but has not begunOPENING, // server has begun to open but not yet doneOPEN, // server opened region and updated metaPENDING_CLOSE, // sent rpc to server to close but has not begunCLOSING, // server has begun to close but not yet doneCLOSED, // server closed region and updated metaSPLITTING, // server started split of a regionSPLIT // server completed split of a region

 進一步發現是load balance的問題 region server不停重複的被open close，參考http://abloz.com/hbase/book.html#regions.arch.assignment  重啟了region server正常

後來的代碼運行中又出現region not on line ，是NotServingRegionException拋出的，原因是“Thrown by a region server if it is sent a request for a region it is not serving.”

 為什麼會不斷請求一個離線的region？且這種錯誤集中在150個中的3個region，追蹤伺服器端log，region 會被CloseRegionHandler關掉，過了20分鐘左右才重新開啟，關掉後用戶端請求的region仍然是這個關閉的region？

 

 

3 設定開關不寫入hbase並不生效

代碼初上線，增加了開關，萬一hbase有問題則關閉掉開關。但是出現問題了發現程式卡死，目前認為原因是不斷加長的retry機制，60秒逾時，1-32秒的10次retry，萬一出問題，切換開關也沒有用。

需要配置rpc逾時參數和retry time解決它

 

4 flush、split、compact導致stop-the-world

出現長時間的flush split操作導致hbase伺服器端無法響應請求。需要調整region大小，並測試擷取flush次數

 

5 hbase參數設定

hbase.regionserver.handler.count

考慮到sas盤的io能力，設定為50

hbase.hregion.memstore.block.multiplier

當memstore的大小為hbase.hregion.memstore.flush.size的multiplier倍數時，阻塞讀寫進行flush，預設為2

 

6 region server crush

Regionserver crash的原因是因為GC時間過久導致Regionserver和zookeeper之間的串連timeout。

Zookeeper內部的timeout如下：

minSessionTimeout 單位毫秒，預設2倍tickTime。

maxSessionTimeout 單位毫秒，預設20倍tickTime。

（tickTime也是一個配置項。是Server內部控制時間邏輯的最小時間單位）

如果用戶端發來的sessionTimeout超過min-max這個範圍，server會自動截取為min或max，然後為這個Client建立一個Session對象。

預設的tickTime是2s，也就是用戶端最大的timeout為40s，及時regionserver的zookeeper.session.timeout設定為60s也沒用。

 

改動：

1. 將zookeeper叢集的tickTime修改為9s，最大的timeout為180s，同時修改zookeeper.session.timeout為120s，這樣可以避免GC引發timeout。
2. 添加參數hbase.regionserver.restart.on.zk.expire為true，改參數的作用是當regionserver和zookeeper之間timeout之後重啟regionserver，而不是關掉regionserver。

 

7 代碼問題導致死結

master慢查詢日誌中一個查詢達到了2小時，最終導致伺服器響應變慢，無法應對大寫入。追究原因是getColumns操作一下取出十幾萬的資料，沒有做分頁；更改程式分頁500條左右，目前沒有出現問題

 

8 operation too slow

2012-07-26 05:30:39,141 WARN org.apache.hadoop.ipc.HBaseServer: (operationTooSlow): {"processingtimems":69315,"ts":9223372036854775807,"client":"10.75.0.109:34780","starttimems":1343251769825,"queuetimems":0,"class":"HRegionServer","responsesize":0,"method":"delete","totalColumns":1,"table":"trackurl_status_list","families":{"sl":[{"timestamp":1343251769825,"qualifier":"zzzn1VlyG","vlen":0}]},"row":""}
刪除一行資料用了69315s

而且神奇的是row為""，row無法設定null進去，但可以增加空串。做了一輪測試
空row-key  刪除不存在的column  耗時 700ms

空row-key  刪除存在的column  耗時 5ms

非空row-key  刪除任意的column  耗時 3ms

不清楚是否是個bug，也還不知道怎麼就傳了個空row-key進去，目前策略為在代碼端避免對空row-key做操作。

9 responseTooSlow

2012-07-31 17:52:06,619 WARN org.apache.hadoop.ipc.HBaseServer: (responseTooSlow): {"processingtimems":1156438,"call":"multi(org.apache.hadoop.hbase.client.MultiAction@3dbb29e5), rpc version=1, client version=29, methodsFingerPrint=-1508511443","client":"10.75.0.109:35245","starttimems":1343727170177,"queuetimems":0,"class":"HRegionServer","responsesize":0,"method":"multi"}

引用hbase說明：The output is tagged with operation e.g. (operationTooSlow) if the call was a client operation, such as a Put, Get, or Delete, which we expose detailed fingerprint information for. If not, it is tagged (responseTooSlow) and still produces parseable JSON output, but with less verbose information solely regarding its duration and size in the RPC itself.

目前做法是取消了對某個key多個column的批量delete操作避免阻塞，沒有發現新問題

10 output error

2012-07-31 17:52:06,812 WARN org.apache.hadoop.ipc.HBaseServer: IPC Server Responder, call get([B@61574be4, {"timeRange":[0,9223372036854775807],"totalColumns":1,"cacheBlocks":true,"families":{"c":["ALL"]},"maxVersions":1,"row":"zOuu6TK"}), rpc version=1, client version=29, methodsFingerPrint=-1508511443 from 10.75.0.151:52745: output error

11 rollbackMemstore問題

較頻繁出現這樣的log：
2012-08-07 10:21:49,887 DEBUG org.apache.hadoop.hbase.regionserver.HRegion: rollbackMemstore rolled back 0 keyvalues from start:0 to end:0

方法解釋為：Remove all the keys listed in the map from the memstore. This method is called when a Put has updated memstore but subequently fails to update the wal. This method is then invoked to rollback the memstore.

很奇怪的是開始和結束的index都為0   

方法中迴圈： for (int i = start; i < end; i++) {  

因此是空資料，空復原。需要進一步調查

 

12 新上線一個region server  導致region not on line

往錯誤的region server伺服器請求region

 

13 請求不存在的region，重建立立tablepool也不起作用

請求的時間戳記 1342510667

最新region rowkey相關時間戳記 1344558957

最終發現維持region location表的屬性是在HConnectionManager中

get Get，delete Delete，incr Increment 是在 ServerCallable類 withRetries處理

   情景1 若有出錯（SocketTimeoutException ConnectException RetriesExhaustedExcetion），則清理regionServer location

   情景2 numRetries 若設定為1 ，則 迴圈只執行一次，connect(tries!=0) 為connect(false),即reload=false，不會進行location更新，當為numRetries>1的時候才會重新擷取

get Gets List, put Put或Puts List，delete Deletes List 則調用HConnectionManager的 processBatch去處理，當發現批量get或者put、delete操作結果有問題，則重新整理regionServer location

設定 numRetries為>1次， 我這裡是3次，解決問題

14 zookeeper.RecoverableZooKeeper(195): Possibly transient ZooKeeper exception: org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = ConnectionLoss for /hbase/master

這是在我單機做測試時出現的，無論是從ide或是bin啟動hbase，從shell裡可以正常串連，從測試程式中無法串連，zookeeper連接埠是2181,用戶端連接埠應該與zookeeper無關才對，

最終更改配置21818連接埠換為2181 運行正常，應該是單機環境才要做這種更改。

<property>    <name>hbase.zookeeper.property.clientPort</name>    <value>2181</value>    <description>Property from ZooKeeper's config zoo.cfg.    The port at which the clients will connect.    </description>  </property>