Kouhei Sutou
kou****@clear*****
2016年 12月 5日 (月) 14:26:31 JST
須藤です。 In <20161****@orega*****> "[groonga-dev,04199] Re: PGROONGAでレコード追加時にエラー発生" on Thu, 01 Dec 2016 17:31:40 +0900, 高見 直輝 <takam****@orega*****> wrote: >> pgroonga.flush_explicitly = true >> みたいなパラメーターを用意してtrueならINSERT/DELETE/UPDATE後 >> やCREATE INDEX後に（OSのディスク書き出しタイミングに任せずに） >> ディスクに書き出すようにしようかと思っています。 > > この機能によって、ハード障害などが原因の場合にもデータの破損を回避できるようになるのでしょうか？ ハード障害というのはディスクが壊れたとかも想定していますか？ であれば、回避できません。 なお、そのレベルで壊れるとPostgreSQLでも回避できません。壊れ たディスクのデータは信用できないので、そこからWALで復旧して も正常な状態にならないかもしれないからです。 なので、そのレベルの状態からの復旧を考えるのであれば、バック アップをとるとか、レプリケーションして同じものを別のディスク にも用意しておくとか、そういうレベルでの対応を考える必要があ ります。 で、私はそういうレベルの壊れるではなく、OSのシャットダウンな どでPostgreSQLのプロセスが強制終了されることによる破損を想定 していました。 > データ破損を完全に回避することができないのであれば、以下のようなエラー発生時用の機能の方が重要か > もしれません > ・ロック中のオブジェクトの一覧取得 これは、PostgreSQL起動前にgrndb checkをすることでわかります。 ただ、ロックには取得時刻情報はない（そういうものを入れるとロッ クのオーバーヘッドが大きくなる）ので > →ロック取得日時が分かれば、再起動によって解放されないロックか判断可能。 はできません。 > ・エラーの対象（ロックの場合、データベースORテーブル） > →毎回、全テーブル再構築をしなくて済む。 これもgrndb checkでわかります。 > ・データの破損（SQL実行時にエラーが発生するレベルのもの） これは。。。フラッシュされずにプロセスが死んだ（OSのシャット ダウンでPostgreSQLが強制終了した場合など）場合はどのくらいディ スクに書き込まれたかがわからないので、壊れているかもしれない し壊れていないかもしれない、くらいまでしかわからないんですよ ねぇ。 >> どのくらいかわかりませんが、たぶん書き込みパフォーマンスは落 >> ちるのでデフォルトでは有効にしたくないのですが、↑のように必 >> 要な人だけが有効にする、ならアリかなぁと思っています。 > > 各コマンド毎にFlushが行われるのは、パフォーマンスが落ち過ぎるような気がします。 > トランザクションのコミット毎なら、許容範囲に収まるのではないでしょうか？。 残念ながらPostgreSQLはPGroongaにコミットのタイミングを通知し てくれないのです。。。 最終変更時刻からn秒後にフラッシュ（更新が連続していればフラッ シュされない）くらいがいいんですかねぇ。 -- 須藤 功平 <kou****@clear*****> 株式会社クリアコード <http://www.clear-code.com/> Groongaベースの全文検索システムを総合サポート: http://groonga.org/ja/support/ パッチ採用 - プログラミングが楽しい人向けの採用プロセス: http://www.clear-code.com/recruitment/ リーダブルコードワークショップ: http://www.clear-code.com/services/code-reader/readable-code-workshop.html
