高見 直輝
takam****@orega*****
2016年 12月 5日 (月) 17:04:28 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のディスク書き出しタイミングに任せずに） > >> ディスクに書き出すようにしようかと思っています。 > > > > この機能によって、ハード障害などが原因の場合にもデータの破損を回避できるようになるのでしょうか？ > > ハード障害というのはディスクが壊れたとかも想定していますか？ > であれば、回避できません。 いいえ。記憶領域の物理的な破損については想定していません。 想定しているのは以下のような場合です。 ・高負荷などによってディスク書き込みが失敗した ・外付けのHDDで、ケーブルが抜けた等の理由により書き込みが停止した いずれも、時間の経過やユーザによる復旧処理で回復するものです。 > なお、そのレベルで壊れるとPostgreSQLでも回避できません。壊れ > たディスクのデータは信用できないので、そこからWALで復旧して > も正常な状態にならないかもしれないからです。 > > なので、そのレベルの状態からの復旧を考えるのであれば、バック > アップをとるとか、レプリケーションして同じものを別のディスク > にも用意しておくとか、そういうレベルでの対応を考える必要があ > ります。 > > で、私はそういうレベルの壊れるではなく、OSのシャットダウンな > どでPostgreSQLのプロセスが強制終了されることによる破損を想定 > していました。 この場合、先述のパラメータで破損を完全に回避することが可能なのでしょうか？ タイミング次第ですが、パラメータをONにしても発生し得るのでは？ > > データ破損を完全に回避することができないのであれば、以下のようなエラー発生時用の機能の方が重要か > > もしれません > > ・ロック中のオブジェクトの一覧取得 > > これは、PostgreSQL起動前にgrndb checkをすることでわかります。 PostgreSQLを停止しなくて良い手段は在りませんでしょうか？ PGROONGAと無関係な処理は継続したいのです。 そういう意味では、現状の復旧手段である『DBを停止してPGROONGAのファイルを削除する』についても、 GROONGAのコマンドで全データのクリア（初期化）が出来るのが望ましいです。 > ただ、ロックには取得時刻情報はない（そういうものを入れるとロッ > クのオーバーヘッドが大きくなる）ので > > > →ロック取得日時が分かれば、再起動によって解放されないロックか判断可能。 > > はできません。 > > > ・エラーの対象（ロックの場合、データベースORテーブル） > > →毎回、全テーブル再構築をしなくて済む。 > > これもgrndb checkでわかります。 > > > ・データの破損（SQL実行時にエラーが発生するレベルのもの） > > これは。。。フラッシュされずにプロセスが死んだ（OSのシャット > ダウンでPostgreSQLが強制終了した場合など）場合はどのくらいディ > スクに書き込まれたかがわからないので、壊れているかもしれない > し壊れていないかもしれない、くらいまでしかわからないんですよ > ねぇ。 壊れている（かもしれない）対象を、Postgreのエラー（メッセージ）に仕込むことは出来ませんか？ 内情がどうあれ、レコードの追加が出来ない以上、対応は必要になります。 また、GROONGAのインデックスの量に応じて復旧にかかる時間が延びるため、大量のデータが存在する環境 では再構築に2日かかった事例が存在しています。 当方の環境ではテーブルを分割しているので、対象が特定できれば、そしてそれが１つのテーブルだけであ れば、現状の『全テーブルに対してインデックス再構築』に要する時間を大幅に減らすことが可能になります。 > >> どのくらいかわかりませんが、たぶん書き込みパフォーマンスは落 > >> ちるのでデフォルトでは有効にしたくないのですが、↑のように必 > >> 要な人だけが有効にする、ならアリかなぁと思っています。 > > > > 各コマンド毎にFlushが行われるのは、パフォーマンスが落ち過ぎるような気がします。 > > トランザクションのコミット毎なら、許容範囲に収まるのではないでしょうか？。 > > 残念ながらPostgreSQLはPGroongaにコミットのタイミングを通知し > てくれないのです。。。 これって、ロールバックが行われた場合、どうなるのでしょうか？ 内部的にはレコードの削除が通知されてくる？ > 最終変更時刻からn秒後にフラッシュ（更新が連続していればフラッ > シュされない）くらいがいいんですかねぇ。 Create・Drop Indexとそれ以外のコマンドで、壊れる範囲が変わることがあるのでしょうか？ それでしたら、破損範囲の特定という観点から、Create・Drop Indexとそれ以外の設定を分けた方が良いと 思います。 ----------------------------- 高見 直輝 <takam****@orega*****> 株式会社オレガ TEL:03-3267-0150 FAX:03-3267-0180
