高見 直輝
takam****@orega*****
2016年 12月 6日 (火) 10:37:13 JST
高見です。 > 須藤です。 > > In <20161****@orega*****> > "[groonga-dev,04203] Re: PGROONGAでレコード追加時にエラー発生" on Mon, 05 Dec 2016 17:04:28 +0900, > 高見 直輝 <takam****@orega*****> wrote: > > >> ハード障害というのはディスクが壊れたとかも想定していますか？ > >> であれば、回避できません。 > > > > いいえ。記憶領域の物理的な破損については想定していません。 > > 想定しているのは以下のような場合です。 > > ・高負荷などによってディスク書き込みが失敗した > > ・外付けのHDDで、ケーブルが抜けた等の理由により書き込みが停止した > > いずれも、時間の経過やユーザによる復旧処理で回復するものです。 > > よくわかっていないんですが、このケースはPostgreSQL本体は回避 > できるのでしょうか？ 回避は出来ませんが、“リカバリモード”となって自動的に復旧します。 この間、DBにアクセスできません（エラーとなります）が、10分程度待てば使えるようになります。 > > この場合、先述のパラメータで破損を完全に回避することが可能なのでしょうか？ > > 完全には回避できません。 であれば、破損が発生する前提で、復旧に関する機能の拡充をした方が良いと思います。 > > タイミング次第ですが、パラメータをONにしても発生し得るのでは？ > > 書き込んだ後、フラッシュ前にクラッシュすれば発生します。 > > >> これは、PostgreSQL起動前にgrndb checkをすることでわかります。 > > > > PostgreSQLを停止しなくて良い手段は在りませんでしょうか？ > > PGROONGAと無関係な処理は継続したいのです。 > > 「PGroongaと無関係な処理だけ」している状態であればgrndbを使っ > ても問題ないです。使っている側でそこを保証した状態で使うのは > どうでしょうか。 > > > そういう意味では、現状の復旧手段である『DBを停止してPGROONGAのファイルを削除する』についても、 > > GROONGAのコマンドで全データのクリア（初期化）が出来るのが望ましいです。 > > pgroonga.enable = falseみたいな接続してもPGroongaがGroongaの > DBを開かないみたいなモードを用意してその状態で削除、みたいな > 感じなら実現可能です。 DBを起動したまま切り替えることができ、falseにしたときに既存の接続を強制切断してくれると更に良い ですね。 復旧のことを考えると、これがfalseの状態でインデックスの削除が実行できるのが理想です。 > そういう感じの制限なしでは無理です。Windowsでは別のプロセス > がファイルを開いているとファイルを消せない制限とかがあるので、 > 複数の接続がGroongaのDBを触っている状態で削除して作り直す、 > とかはできないんです。 この点は理解しています。ただ、PostgreSQLをシャットダウンした状態でないと復旧できないというのは、 対処のコストが跳ね上がるので何とかして頂ければと思う次第です。 > >> > ・データの破損（SQL実行時にエラーが発生するレベルのもの） > >> > >> これは。。。フラッシュされずにプロセスが死んだ（OSのシャット > >> ダウンでPostgreSQLが強制終了した場合など）場合はどのくらいディ > >> スクに書き込まれたかがわからないので、壊れているかもしれない > >> し壊れていないかもしれない、くらいまでしかわからないんですよ > >> ねぇ。 > > > > 壊れている（かもしれない）対象を、Postgreのエラー（メッセージ）に仕込むことは出来ませんか？ > > 内情がどうあれ、レコードの追加が出来ない以上、対応は必要になります。 > > ロックが残っている場合はレコード追加時のエラーメッセージにで > ませんでしたっけ？ 出る場合と出ない場合があります。 出る ：pgroonga: failed to create table: grn_table_add failed: <Sources45756> 出ない：pgroonga: failed to set column value: check_jump failed なんとなくですが、テーブルの追加・削除では出て、レコードの追加・削除では出ないような気がします。 あと、テーブルの追加・削除時のエラーは、対象のオブジェクトではなくpgrnファイルに問題がある場合が 多い印象です。 ※エラー検出の方でも質問していますが、check_jump failedを再現する方法がありましたら教えて下さい。 > > また、GROONGAのインデックスの量に応じて復旧にかかる時間が延びるため、大量のデータが存在する環境 > > では再構築に2日かかった事例が存在しています。 > > 当方の環境ではテーブルを分割しているので、対象が特定できれば、そしてそれが１つのテーブルだけであ > > れば、現状の『全テーブルに対してインデックス再構築』に要する時間を大幅に減らすことが可能になります。 > > そのあたりをやってくれるのがgrndb recoverなので、「PGroonga > と無関係な処理だけ」している状態を保証してgrndbを使うのがよ > いのではないかと思いました。 ドキュメントのgrndbのページでは『実験的な機能』という扱いなのですが、事実上の正式版という認識で 良いのでしょうか？ あと、当方はWindows環境なのでRubyのコードをEXE化しようと考えています。 何か情報をお持ちでしたら教えて下さい。 > >> 残念ながらPostgreSQLはPGroongaにコミットのタイミングを通知し > >> てくれないのです。。。 > > > > これって、ロールバックが行われた場合、どうなるのでしょうか？ > > 内部的にはレコードの削除が通知されてくる？ > > PostgreSQLはロールバックしてもすぐにはレコードを削除しません。 > VACUUMのタイミングで削除しています。 > > >> 最終変更時刻からn秒後にフラッシュ（更新が連続していればフラッ > >> シュされない）くらいがいいんですかねぇ。 > > > > Create・Drop Indexとそれ以外のコマンドで、壊れる範囲が変わることがあるのでしょうか？ > > あります。CREATE INDEX/DROP INDEXのときはpgrnファイル自体が > 壊れる可能性があります。 なら、この２つのコマンドに関しては、強制的に実行するくらいでいいかもしれません。 ----------------------------- 高見 直輝 <takam****@orega*****> 株式会社オレガ TEL:03-3267-0150 FAX:03-3267-0180
