高見 直輝
takam****@orega*****
2016年 11月 22日 (火) 18:03:00 JST
お世話になります。高見です。 各コマンドの実行結果が取得できました。 該当したのはcolumn_listの結果の方でした。 [387,"_key","","","COLUMN_SCALAR","Lexicon16916_0","ShortText",[]] [389,"index","base/16384/pgrn.0000185","index","COLUMN_INDEX|WITH_POSITION|PERSISTENT","Lexicon16916_0","Sources16916",["Sources16916.lower"]] 現在、一つのテーブルにPGROONGAを使用するインデックスが5つ存在しており、Lexicon【数値】の数値部分 が５つずつ連番になっています。 例）16101、16102、16103、16104、16105 16256、16257、16258、16259、16260 上記のデータはその連番の中で最後尾のものとなっています。 ここから、追加の報告となります。 現在障害が発生している環境とは別に、もう一つ、ほぼマシンスペック、運用状況などが同等の環境が稼働 していました。 そちらの環境は先週まで正常に稼働していたのですが、今週になってから、同様のエラーが発生するように なりました。 これに対しても各種コマンド実行によってログを取得したところ、上記とほぼ同じ結果が得られました。 [367,"_key","","","COLUMN_SCALAR","Lexicon16907_0","ShortText",[]] [369,"index","base/16384/pgrn.0000171","index","COLUMN_INDEX|WITH_POSITION|PERSISTENT","Lexicon16907_0","Sources16907",["Sources16907.lower"]] 異なるのは以下の二点です。 ・各種オブジェクト名の数値部分の値 ・連番の中の位置が、上記は最後尾だったが、こちらは先頭 以上です。 前回報告した下記の件と併せて確認をお願いします。 > まず、添付ファイルについて。 > これまで報告してきた状況と、よく似た問題が全く異なる環境で発生しました。 > このファイルは、その環境で採取したログファイルです。 > これまでのものとの違いは、ファイルのエラーと並行して、base/16384/pgrnに対するエラーが存在してい > る点です。 > これは同じ原因であると考えて良いのでしょうか？ > 確認をお願いします。 > > 以下、インラインにて。 > > > クリアコード 結城です。 > > > > > > > まず、提示していただいたコマンドを実行するのは困難な状態です。 > > > （実行すると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 > > > > この方法は可能でしょうか？ > > 実行が困難と判断した理由は、稼働環境の管理者とのやり取りの都合上、table_listの実行とcolumn_list > の実行の間に空白が出来てしまうからです。（まずtable_listの実行結果を送ってもらい、その結果をもと > にcolumn_listのバッチを作成して送る、という手順を踏む必要があるため。） > 先週末に問題が再発しまして、このときログに出力されていたのが前回と同じpgrn.0000185に対するもので > あったことから、日単位の空きが有っても問題無いと考え、コマンドを実行してもらうことにしました。 > 今週後半あたりには、コマンドの実行結果を報告できると思います。 > > > > そこで確認なのですが、ロックが外部のアプリケーション（ウィルススキャ > > ンソフトなど）によって取られている可能性は > > > ありませんでしょうか？ > > > > この可能性は0とは言えないと考えられます。 > > 今週末も同様のエラーが出ていて、ログに現れているファイルのパスが先週末と > > 一致している場合、ファイルの破損やオブジェクトがロックされたままの状態に > > なっているという可能性があります。 > > 逆に、エラーの原因となっているファイルのパスが先週末とは異なる場合、外部 > > のアプリケーションがたまたまその時ロックしていたファイルがエラーの原因に > > なっている、という可能性があります。 > > 前述の通り、現状は一つ目の条件と合致しています。 > ただ、DBのデータフォルダをウィルススキャンソフトの対象外としている状態なので、スキャンソフトが原 > 因の可能性は低いようです。 > > > > また、対象のファイルの作成日時の比較などから、ある程度推測することは > > 出来ませんでしょうか？ > > > > 他のファイル群と比較して何か際立って特徴的な作成日時になっているようであ > > れば、それが何かヒントになるかのうせいはあると思われます。 > > 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
