高見 直輝
takam****@orega*****
2015年 7月 22日 (水) 12:43:00 JST
高見です。 ファイルハンドルのロック状況が気になったので調べてみました。 使用したツール：OpenedFilesView http://www.nirsoft.net/utils/opened_files_view.html この結果、PGRN系のファイルに関して、『Shared Delete』が指定されていない ことが判明しました。（PostgreSQLの他のファイルは指定されている） これが削除時にエラーになる原因の可能性はありますでしょうか？ > > 対策を入れたソースアーカイブを作ったのでこれで試してみてもら > > えますか？ > > > > http://packages.groonga.org/tmp/pgroonga-0.8.0-20150717.zip > > ありがとうございます。 > 確認しましたので結果報告を。 > > > PGroongaじゃなくてGroongaの方を変えて、ファイルの削除に失敗 > > したら削除処理を途中で止めるようにしました。この問題が起きる > > のは、「GroongaのDB内ではインデックスが削除されたけどファイ > > ルは残っている」という状態になるためです。そのため、「ファイ > > ルの削除に失敗したらDBからインデックスを削除しない」というよ > > うにして、GroongaのDB内の情報とファイルの有無の整合性を保つ > > ようにしました。 > > > > （GroongaのDB内でインデックスが削除されるとそのインデックス > > に割り当てられたIDが再利用されます。そのIDがファイル名にも含 > > まれています。再利用されたIDを利用したとき、そのIDを使ってい > > たインデックスがファイルを削除できていない場合に今回の問題が > > 発生します。） > > 上記モジュールにて、これまでエラーとなっていた、 > テーブル削除で内部エラーが出ている状態で、テーブルの作成に失敗する > が解決したことを確認しました。 > > > ただし、VACUUMが走っても使っていないインデックスは削除されな > > いということがあります。接続数が1のときにVACUUMを実行すると > > 削除されるので、もし、常に複数の接続があるしインデックスの削 > > 除をたくさん実行する、というときは運用を工夫（定期的に、接続 > > 数を減らして手動でVACUUMを実行するようにするとか）する必要が > > あります。 > > DB再起動直後のVACUUMで不要ファイルが削除されたのを確認しました。 > 実行タイミングについてですが、VACUUMの対象を絞り込むことが出来れば、 > ハードルが下がるのではないかと思います。 > > > あと、別件になりますが、ログ（pgroonga.log）の設定方法について、マニュア > ルに記載してもらえませんでしょうか？ > レベルの設定方法はvalid.sqlなどから読み取れたのですが、以下の情報がある > と助かります。 > ・ファイルの出力先の変更の可否 > ・ログローテートなど、ディスク使用容量を一定範囲に納める機能の有無 > 以上、宜しくお願いします。 > > > In <20150****@orega*****> > > "[groonga-dev,03367] Re: PGROONGAで障害発生" on Fri, 17 Jul 2015 09:48:38 +0900, > > 高見 直輝 <takam****@orega*****> wrote: > > > > >> > 上記１で、テーブルのファイルが閉じるタイミング（条件）はどうなっているのでしょうか？ > > >> > これが分かれば、プログラムで対応することが可能になるかもしれません。 > > >> > > >> クライアントとの接続が切れるタイミングです。 > > > > > > つまり、DROP文をPSQLコマンドなどで実行することで対応出来る可能性があるわけですね。 > > > > うーん、他の接続がインデックスを開いているとダメなので、別途 > > psqlコマンドを実行するという意味なら効果がないと思います。 > > （逆に接続数が増えてよくない。） > > > > > ログのタイムスタンプからは、DROP文を実行してから数十ミリ秒後にエラーが発生しているように見えました。 > > > PostgreSQL内部ではDROP⇒VACUUMがバッチで実行されているのかもしれません。 > > > > そうなんですかねぇ。手元でも発生するならデバッガーで走らせて > > ブレークポイントをしかければすぐに確認できるのですが、手元で > > は発生しないんですよねぇ。 > > > > >> 不要なテーブルの削除をだれも開いていないことを確認できた状態 > > >> でだけ実行できればいいんですけど。。。FILE_SHARE_DELETEでう > > >> まく動くかと思ったんですが、相変わらずエラーになるんですよ > > >> ねぇ。 > > >> > > > > > > これに関しては発想が逆で、『削除に失敗している状況でも、作成を成功させる』のが目的です。 > > > > なるほど。勘違いしていました。 > > > > > 先日のログで、テーブル作成時に作るファイルの名前を、既存のファイル（pgrn.000042F）ではなく、別の名 > > > 前（例：pgrn.00004AF）で作成してやれば、差し当たりの問題は解決すると思うのですが、どうでしょうか？ > > > > 今回の対応はちょっとそんな感じになりました。 > > > > ファイル名の000042Fとか00004AFのところがGroongaのDB内でのID > > に対応するんですが、結果的にIDを再利用しなくなったので削除に > > 失敗したときは別のファイルを使うようになっています。 ----------------------------- 高見 直輝 <takam****@orega*****> 株式会社オレガ TEL:03-3267-0150 FAX:03-3267-0180
