Kouhei Sutou
kou****@clear*****
2015年 7月 17日 (金) 15:35:07 JST
須藤です。 対策を入れたソースアーカイブを作ったのでこれで試してみてもら えますか？ 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を実行するようにするとか）する必要が あります。 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を再利用しなくなったので削除に 失敗したときは別のファイルを使うようになっています。
