高見 直輝
takam****@orega*****
2016年 12月 1日 (木) 18:41:06 JST
高見です。 各務さん、結城さん、情報提供ありがとうございます。 纏めると、 ・異常を確実に検出する方法は現時点では存在しない。 ・ロックの有無を調べる方法も無い。 ということですね。 実際にエラーが発生したときにこの情報から判断するしかなさそうなので、エラーを意図的に発生させて、 そのときにどのようなメッセージが返ってくるかを調べてみました。 ※先日の障害報告時の『check_jump failed』を意図的に発生させる方法がありましたら教えて下さい。 ●GROONGAのロックコマンド（lock_acquire）を実行⇒DB再起動後テーブル作成 ERROR: 58000: pgroonga: pgroonga: failed to create table: grn_table_add failed: <Sources24959> ●テーブル作成後、ロックコマンド（lock_acquire Sources24977）を実行⇒再起動後レコード追加 エラー発生せず、正常に完了。 ●ファイル（base\16384\pgrn）を適当に編集⇒レコード追加 FATAL: 57P03: the database system is in recovery mode ※以後、上記エラーが出続けるようになった。 ●ファイル（base\16384\pgrn.XXXXX）のサイズを0にする⇒再起動後レコード追加 ERROR: 42602: pgroonga: object isn't found: <Sources24977> ●ファイル（base\16384\pgrn.XXXXX）を外部アプリでロック（読み込み、書き込み禁止）⇒再起動後レコード追加 ERROR: 42602: pgroonga: object isn't found: <Sources24977> ●ファイル（base\16384\pgrn.XXXXX）を外部アプリでロック（書き込み禁止）⇒再起動後レコード追加 ERROR: 42602: pgroonga: object isn't found: <Sources24977> ●ファイル（base\16384\pgrn.XXXXX）を適当に編集⇒再起動後レコード追加 エラー発生せず、正常に完了。 > クリアコード 結城です。 > > データ変更を伴わないインデックスの異常検出の方法としては、やはり各務さん > の事例のように、インデックスを使用する検索と使用しない検索を両方とも実行 > して結果を比較するという方法がまず考えられます。 > ただ、インデックスの破損の仕方によっては異常を検出できない可能性はありま > すので、完璧とは言えないと思われます。 > > ロックの有無を直接調べるコマンドは、残念ながらありません。 > （Groongaのobject_listコマンドを実行すると各オブジェクトの状態を調べられ > ますが、ロックの状態は残念ながら出力されません。） > ロックがかかったままになっているかどうかは、groonga.logにlock failedの > メッセージが出力されているかどうかを見て把握する必要があります。 > > -- > 結城 洋志 <YUKI Hiroshi> > E-mail: yuki****@clear***** > > 株式会社クリアコード > 〒170-0005 東京都豊島区南大塚3-29-9 > 中野ビル3階 > TEL : 03-5927-9440 > FAX : 03-5927-9441 > WWW : http://www.clear-code.com/ > > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > http://lists.osdn.me/mailman/listinfo/groonga-dev ----------------------------- 高見 直輝 <takam****@orega*****> 株式会社オレガ TEL:03-3267-0150 FAX:03-3267-0180
