hbase問題まとめ

10853 ワード

転載先:  http://www.cnblogs.com/shenguanpu/archive/2012/06/12/2546309.html
1 java.io.IOException:java.io.IOException:java.lang.IllagalArtException: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.Retries Exhausted WithDetails Exception: Failed 1 action: Not ServingRegion Exception: 1 タイム、 servers with ises: 10.xx.xx.37:60020、   または org.apache.hadoop.hbase.Not ServingRegionException: Region is not オンライン:  この2つのエラーは、mater-statusにRegions in Transitionが発生してから10分間にわたって、PENDING_にあります.OPEN状態は要求が詰まります.現在、このマシンをオフラインして、一晩安定して運行しています.スピードによる渋滞はありません.機械の問題が疑われます.Hmasterのログはこのregion serverのひっきりなしに続くopen closeを表示して、いかなるsplitあるいはflushをしません.
RITのフルネームはregion in transcationです.毎回hbase masterはregionの一つのopenまたは一つのcloseに操作してマスターのRITに記録を挿入します.マスターはレギオンの操作に原子性を維持します.レギオンのopenとcloseはHmasterとレギオンserverで協力して完成します.これらの操作を満足させるためにロールバックします.HmasterはRIT機構を採用し、ZookeeperのNodeの状態を結合して操作の安全と一致を保証します.
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

 さらに発見されたのは、ロードbalanceの問題region serverが繰り返しているopen closeで、http://abloz.com/hbase/book.html#regions.arch.assignmentを参照してください.  region serverを再起動しました.正常です.
その後のコード運行中にまたregion not on lineが現れました.NotServingRegionExceptionが投げたのです.その理由は「Thrown by region server if it is sent a request for a region it is not」です. serving.
 なぜオフラインのレギオンをお願いし続けますか?そして、このようなエラーは150の中の3つのレギオンに集中しています.サーバーのロゴを追跡します.レギオンはClose RegionHandlerによって停止されます.20分ぐらい経ってから再開します.消した後、クライアントから要求されたレギオンは依然としてこのクローズされたレギオンですか?
 
 
3設定スイッチはhbaseに書き込まないと有効になりません.
コードは最初にオンラインして、スイッチを追加しました.もしhbaseに問題があったら、スイッチを切ります.しかし、問題が発生しました.プログラムがデッドアウトしたのは、現在の原因と考えられているのは、絶えず延長されているretryシステムで、60秒のタイムアウト、1~32秒の10回のretryです.万が一問題が発生したら、スイッチを切り替えても無駄です.
rpcのタイムアウトパラメータとretry timeを設定して解決する必要があります.
 
4 flush、split、compectはstop-the-worldを招きます.
長時間のflush split操作が発生したため、hbaseサーバ側は要求に応じられなくなりました.regionのサイズを調整し、flushの取得回数をテストします.
 
5 hbaseパラメータ設定
hbase.regionserver.handle.com unt
sas盤のio能力を考慮して、50に設定します.
hbase.hregion.memstore.block.multiiplier
memstoreの大きさがhbase.hregion.memstore.flush.sizeのmultilier倍数であるときは、読み書きを中断してflushします.デフォルトは2です.
 
6レギオンserver crush
Regionserver crastの原因は、GCの時間が長すぎてRegionserverとzookeeperとの間の接続timeoutになったからです.
Zookeeper内部のtimeoutは以下の通りである.
minSessionTimeout単位でミリ秒、デフォルトの2倍のtickTime.
maxSession Timeout単位でミリ秒、デフォルトでは20倍のtickTimeです.
(tickTimeも構成項目です.Server内部制御時間論理の最小単位です.)
クライアントから送られてきたsessionTimeoutがmin-maxを超える場合、serverは自動的にminまたはmaxを切り取り、このClientのためにSessionオブジェクトを新規作成します.
デフォルトのtickTimeは2 s、つまりクライアントの最大のtimeoutは40 sで、タイムリーにregionserverのzookeeper.session.timeoutは60 sに設定しても無駄です.
 
変更:
zookeeperクラスタのtickTimeを9 sに変更し、最大のtimeoutを180 sとし、zookeeper.session.timeoutを120 sに修正することで、GC誘発timeoutを回避することができる.パラメーターhbaser.regionserver.regionserver.on.zk.expireをtrueとして追加し、パラメータを変更する役割はregionserverとzookeeperの間でtimeout後にregionserverを再開し、regionserverをオフすることではない. 
7コード問題によるデッドロック
masterの遅い検索ログの一つのクエリは2時間に達しました.最終的にサーバーの応答が遅くなり、大きな書き込みに対応できなくなりました.原因はget Columnsが操作して十数万のデータを取り出して、改ページをしていませんでした.プログラムの改ページは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と解釈します. caled when a Put has udated memstore but subequently fails to udate the wal.This method is then invoked to rollback the memstore.
変なのは始まりと終わりのindexは全部0です.  
方法中サイクル:for(int i=start;i<end;i++){ 
したがって、空のデータです.空のロールバックです.さらに調査が必要です.
 
12新オンラインでレギオンserver region not on lineにつながる
エラーのregion serverサーバにregionを要求します.
 
13存在しないregionを要求しても、tablepoolを再構築しても機能しません.
要求されたタイムスタンプ134251067
最新region rowkey関連タイムスタンプ 1344558957
region location表を維持する属性はHConnectionagerにあると最終的に発見されました.
get Get,delete Delete,incr Increment ServerCallable類withRetriesで処理します.
   シナリオ1にエラーがあったら、regionServer locationをクリアします.
   シナリオ2 numRetriesを1に設定すると、ループは一回だけ実行され、connect(tries!=0)はconnect(false)、すなわちreload=falseであり、location更新は行われません.numRetries>1の時に再取得されます.
get Gets List,put PutまたはPut List、delete Deletes List HConnectionagerのプロcessBatchを呼び出して処理します.大量getまたはput、deleteの操作結果に問題があると発見されたら、regionServer locationを更新します.
設定 num Retriesは1回です.ここは3回です.問題を解決します.
14 zookeeper.Recoverable Zookeeper(195):Possibly transe Zoo Keeper exception:org.apphe.zookeeper.Keeper Exception$Connection Exception:KeeperError Code=Connection Loss for/hbase/master
これは私が単独機でテストをする時に現れたのです.ideまたはbinからhbaseを起動しても、shellから正常に接続できます.テストプログラムから接続できません.zookeeperポートは2181です.クライアントポートはzookeeperと関係がないはずです.
最終的に変更された構成2188ポートを2181に変えて正常に動作します.シングルマシンの環境がこのような変更をするべきです.

    hbase.zookeeper.property.clientPort
    2181
    Property from ZooKeeper's config zoo.cfg.
    The port at which the clients will connect.