高見 直輝
takam****@orega*****
2016年 12月 1日 (木) 17:31:40 JST
高見です。 > 須藤です。 > > In <20161****@orega*****> > "[groonga-dev,04192] Re: PGROONGAでレコード追加時にエラー発生" on Wed, 30 Nov 2016 11:30:10 +0900, > 高見 直輝 <takam****@orega*****> wrote: > > > ケース１＆２双方とも、インデックスファイルの全削除＆再構築で回復しました。 > > ケース２に関しては、DBデータの保存先ドライブが一時切断していた（ログ取得時点では接続が回復してい > > た）ようなので、これがbase/16384/pgrnでのエラーに繋がったのかもしれません。 > > 結果を共有してもらってありがとうございます。 > > pgroonga.flush_explicitly = true > みたいなパラメーターを用意してtrueならINSERT/DELETE/UPDATE後 > やCREATE INDEX後に（OSのディスク書き出しタイミングに任せずに） > ディスクに書き出すようにしようかと思っています。 この機能によって、ハード障害などが原因の場合にもデータの破損を回避できるようになるのでしょうか？ データ破損を完全に回避することができないのであれば、以下のようなエラー発生時用の機能の方が重要か もしれません ・ロック中のオブジェクトの一覧取得 →ロック取得日時が分かれば、再起動によって解放されないロックか判断可能。 ・エラーの対象（ロックの場合、データベースORテーブル） →毎回、全テーブル再構築をしなくて済む。 ・データの破損（SQL実行時にエラーが発生するレベルのもの） など > どのくらいかわかりませんが、たぶん書き込みパフォーマンスは落 > ちるのでデフォルトでは有効にしたくないのですが、↑のように必 > 要な人だけが有効にする、ならアリかなぁと思っています。 各コマンド毎にFlushが行われるのは、パフォーマンスが落ち過ぎるような気がします。 トランザクションのコミット毎なら、許容範囲に収まるのではないでしょうか？。 ----------------------------- 高見 直輝 <takam****@orega*****> 株式会社オレガ TEL:03-3267-0150 FAX:03-3267-0180
