高見 直輝
takam****@orega*****
2016年 9月 15日 (木) 18:00:42 JST
高見です。
まず結果報告を。
インデックスファイル破損時の対応のみを行いました。
この結果、無事復旧しました。ありがとうございます。
以下、インラインにて。
> > 【状態】
> > サーバが不正な停止をしました。（イベントログに、“停止処理が行われないま
> > ま起動処理が実行された”というレコードが残っていた。）
> > おそらく、電源が寸断⇒再起動したのだと思われます。
> > これ以降、テーブルにレコードを追加（Insert文を実行）しようとすると、以下
> > のエラーが発生するようになりました。
> > ERROR: 58000: pgroonga: pgroonga: failed to set column value:grn_io_lock failed
> >
> > この障害を解消するために以下の対応を行いましたが、状況は変わりません。
> > ・DBサービスの再起動
> > ・GROONGAのclearlockコマンドの実行
> > select pgroonga.command('clearlock');
> > →結果：True
> > ・pgroonga.lock_timeoutパラメーターの変更（60秒または1秒）
> > 元々の値は30秒
> > このときのdebugログ（pgroonga.log）を添付します。
>
> ありがとうございます。clearlockを実行した日時はわかりますか？
> 「2016-09-14 13:50:23.251000」よりも前ですか？そうだとすると、
> 全然ロックが解消されていませんね。。。↑の対応中はデータの更
> 新（INSERTやUPDATE）は止めていましたか？
clearlockを実行したのは、このログが出力される前です。
コマンド実行時は、テーブルデータへのアクセスは一切行っておりません。
> > あとは、PGROONGAのファイルを全て削除してインデックス再作成を実行する（イ
> > ンデックスファイルの破損時の対応）くらいしか思い付かないのですが、これで
> > 直る可能性はありますでしょうか？
> > これ以外の復旧方法の情報などありましたら、教えて下さい。
>
> 試していないのですが、REINDEX + VACUUM FULLでもいけるかもし
> れません。
>
> REINDEXをすることによりインデックスを再作成するのは↑の方法
> と同じです。インデックス再作成後にVACUUM FULLが走ると古いイ
> ンデックスを削除するのですが、それがロックがかかっているカラ
> ムを削除してくれそうな気がしています。削除中にもロックをとろ
> うとするとダメなのですが、とらなそうな気がするので、この方法
> でも復旧できそうな気がします。
>
> ↑の対応と同じくらい時間がかかりそうなので、どっちもどっちか
> もしれません。
所要時間に大差が無い＆復旧できるかどうか未知数な部分があるということで、
インデックス破損時の対応を行いました。
> あとは、PostgreSQLを終了して、↓を実行するというやり方でもい
> けるかもしれません。
>
> > grndb check C:\...\base\16384\pgrn
> > grndb recover C:\...\base\16384\pgrn
残念ながら、grndbコマンドはRubyの実行環境を用意できなかったため試せませ
んでした。
> grndb recoverで自動復旧できないときは「インデックスファイル
> 破損時の対応」でなければいけません。
-----------------------------
高見 直輝 <takam****@orega*****>
株式会社オレガ
TEL:03-3267-0150
FAX:03-3267-0180