YUKI Hiroshi
yuki****@clear*****
2016年 11月 18日 (金) 19:24:18 JST
クリアコード 結城です。 > まず、提示していただいたコマンドを実行するのは困難な状態です。 > （実行するとpgroonga.logに全ファイルの一覧を出力するコマンドが欲し い・・・。） PGroongaが動作しているサーバー上でGroongaのgroongaコマンドを実行可能な場 合、PGroongaが作成したGroongaデータベースをgroongaコマンドで参照する事に よっても同様の調査を行う事ができます。例えば以下の要領です。 $ groonga /path/to/pgroonga/internal/database table_list $ groonga /path/to/pgroonga/internal/database column_list TableName この方法は可能でしょうか？ > そこで確認なのですが、ロックが外部のアプリケーション（ウィルススキャ ンソフトなど）によって取られている可能性は > ありませんでしょうか？ この可能性は0とは言えないと考えられます。 今週末も同様のエラーが出ていて、ログに現れているファイルのパスが先週末と 一致している場合、ファイルの破損やオブジェクトがロックされたままの状態に なっているという可能性があります。 逆に、エラーの原因となっているファイルのパスが先週末とは異なる場合、外部 のアプリケーションがたまたまその時ロックしていたファイルがエラーの原因に なっている、という可能性があります。 > また、対象のファイルの作成日時の比較などから、ある程度推測することは 出来ませんでしょうか？ 他のファイル群と比較して何か際立って特徴的な作成日時になっているようであ れば、それが何かヒントになるかのうせいはあると思われます。 PGroongaが作成したGroongaデータベースの全ファイルの作成日時や最終更新日 時の一覧をご提供いただく事は可能でしょうか？ 高見 直輝 wrote: > 高見です。 > 確認ありがとうございます。 > > まず、提示していただいたコマンドを実行するのは困難な状態です。 > （実行するとpgroonga.logに全ファイルの一覧を出力するコマンドが欲しい・・・。） > > そこで確認なのですが、ロックが外部のアプリケーション（ウィルススキャンソフトなど）によって取られている可能性は > ありませんでしょうか？ > また、対象のファイルの作成日時の比較などから、ある程度推測することは出来ませんでしょうか？ > >> クリアコード 結城です。 >> 反応が遅れて申し訳ありません。 >> >> ログには、ファイル「base/16384/pgrn.0000185」に対するロックの取得を試み >> て失敗している旨が出力されていました。 >> このファイルはデータベース中のいずれかのテーブルのカラムかインデックスに >> 対応していると思われますが、ログからは特定できません。 >> >> このファイルが何なのかは、table_list や column_list といったGroongaのコ >> マンドを使って調べる事で特定できると思われます。 >> https://pgroonga.github.io/ja/tutorial/#groonga >> こちらで紹介されている、PGroongaからGroongaのコマンドを直接実行する方法 >> を使うと、以下のように実行することになります。 >> >> SELECT pgroonga.command('table_list'); >> SELECT pgroonga.command('column_list テーブル名'); >> >> これらのコマンドの出力結果の中に現れる、上記のファイルパスを含んだ項目 >> が、ファイルに対応するオブジェクトとなります。 >> この方法でファイルに対応するオブジェクトを特定していただく事は可能でしょ >> うか？ >> >> >> >> >> 高見 直輝 wrote: >>> クリアコード 結城さま >>> お世話になります。高見です。 >>> >>> 本件、今週中の返答が可能かどうか、教えていただくことは出来ませんでしょうか。 >>> よろしくお願いします。 >>> >>>> >>>> 週単位で、前回とほぼ同じタイミング（金曜夕方）に再発しました。 >>>> ログが取得できましたので、添付します。 >>>> ※障害が発生するようになってから、ログレベルをDEBUGに切り替えています。 >>>> >>>> よろしくお願いします。 >>>> >>>>> クリアコード 結城です。 >>>>> >>>>> > 【状態】 >>>>> > データ登録（INSERT文実行）時、以下のエラーが発生するようになりました。 >>>>> > ERROR: 58000: pgroonga: pgroonga: failed to set column value: >>>>> check_jump failed >>>>> > このエラーはOSの再起動を行っても出続けていたが、ある時を境に出なくな >>>>> りました。 >>>>> > ※分かっている範囲で、土曜の段階から出続けていて、昨日20時半から出なく >>>>> なった。 >>>>> > >>>>> > エラーの詳細について、教えて下さい。 >>>>> > 再発するかどうかが懸念点なので、発生原因と自然回復した理由が分かると >>>>> 助かります。 >>>>> >>>>> このエラーメッセージは、カラムに値を設定している最中、具体的にはインデッ >>>>> クス更新処理の最中に「check_jump」という処理に失敗した事を示しています。 >>>>> 時間経過によってエラーが出なくなった事については、「データベース内のイン >>>>> デックスの状態が更新されて、エラーの原因になっている箇所が使われなくなっ >>>>> た」などの可能性が考えられますが、現時点では理由は不明です。 >>>>> そのため、再発の可能性は否定できません。 >>>>> >>>>> pgroonga.logに「check_jump」失敗時の詳しい情報が出力されていると思われます。 >>>>> 調査のためpgroonga.logをご提供いただく事は可能でしょうか？ >>>>> >>>>> なお、Groonga 6.1.0では修正点の1つとして、インデックス更新処理の不具合の >>>>> 修正がありました。 >>>>> 今回の問題の原因がこの修正の対象箇所だった場合、Groonga 6.1.0をバンドル >>>>> しているPGroonga 1.1.6のバージョンでは問題が解消されている可能性があります。 >>>>> >>>>> >>>>> >>>>> 高見 直輝 wrote: >>>>>> お世話になります。高見です。 >>>>>> 04175の件とは別件のエラーについての質問です。 >>>>>> ※04175は諸般の事情で話が止まっており、現状では報告できることがありません。 >>>>>> >>>>>> 【環境】 >>>>>> PostgreSQL：9.4.5 >>>>>> PGROONGA：1.1.3 >>>>>> >>>>>> 【状態】 >>>>>> データ登録（INSERT文実行）時、以下のエラーが発生するようになりました。 >>>>>> ERROR: 58000: pgroonga: pgroonga: failed to set column value: check_jump failed >>>>>> このエラーはOSの再起動を行っても出続けていたが、ある時を境に出なくなりました。 >>>>>> ※分かっている範囲で、土曜の段階から出続けていて、昨日20時半から出なくなった。 >>>>>> >>>>>> エラーの詳細について、教えて下さい。 >>>>>> 再発するかどうかが懸念点なので、発生原因と自然回復した理由が分かると助かります。 >>>>>> >>>>>> 以上、よろしくお願いします。 > > ----------------------------- > 高見 直輝 <takam****@orega*****> > 株式会社オレガ > TEL:03-3267-0150 > FAX:03-3267-0180 > > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > http://lists.osdn.me/mailman/listinfo/groonga-dev > -- 結城 洋志 <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/
