Kouhei Sutou
kou****@clear*****
2016年 7月 5日 (火) 23:12:23 JST
須藤です。 In <20160****@orega*****> "[groonga-dev,04063] PGROONGAのインデックス破損からの復旧について" on Fri, 01 Jul 2016 14:17:38 +0900, 高見 直輝 <takam****@orega*****> wrote: > 以前（groonga-dev,03925）教えて頂いた障害発生時の復旧手順 > について検証しましたので報告します。 ありがとうございます！ > 【目的】 > 複数のテーブルが存在する状態で、一部のテーブルのみ復旧した時点で利用を開始し、 > 残りのテーブルの復旧をバックグラウンドで行えるようにする。 > > 【環境】 > PostgreSQL：9.4.5 > PGROONGA：1.0.2 > > ●PGRNファイルの全削除 > 1.PostgreSQLの完全停止 > 2.データフォルダ内PGROONGA関連ファイルを全て削除 > 3.PostgreSQLを起動 > 4.インデックス再構築（REINDEXコマンドを実行） > > 上記4の実行待ちのテーブルに対して、各種操作を行った場合の挙動を調べました。 > VACUUM実行：エラー発生せず > ANALYZE実行：「WARNING: pgroonga: object isn't found」が発生 > レコード操作：PostgreSQLのエラー（42602）が発生し、実施できなかった > 検索（Where句無し）：エラー発生せず > 検索（PGROONGA使用）：エラー発生せず（※） > ※：PGROONGAのインデックスに対する条件指定が無視されているように見える 実行待ち（インデックス再構築中）のテーブルに対する操作はそう なると思います。 REINDEXではなく、DROP INDEX + CREATE INDEX CONCURRENTLYにす ると、インデックス構築中でもエラーが発生しなくなると思います。 > 次に、PGROONGAを使用しているテーブルが複数ある状態で、その中の１つだけ > インデックス再構築を実行し、そのテーブルに対して上記の各種操作を行ったと > ころ、全ての操作において問題は発生しませんでした。 よかったです！ > ●PGROONGAのTRUNCATEコマンドの利用 > １．PGROONGAのtable_listコマンドで内部テーブル名一覧を取得 > ２．１の一覧内のSourcesXXXテーブルに対してPGROONGAのTRUNCATコマンドを実行 > ３．インデックス再構築 > > ２と３の間にファイル全削除のときと同様の検証を行ったところ、全ての操作でエラーが > 発生しなかった。 よかったです！ > ただ、次の4ファイルが3を実行しても更新されなかった。 > pgrn > pgrn.0000000 > pgrn.001 > pgrn.conf > これらのファイルが破損した場合、この方法で100%復旧出来るかどうかは不明。 pgrn.confはPostgreSQLを停止（あるいはすべての接続を切断）し た状態でファイルを削除して接続しなおせば新しく作りなおされま す。 他の3つのファイルはたしかにこの方法では復旧できないです。 これらのファイルはできるだけ壊れないように、更新したらすぐに フラッシュするようにした方がいいかもしれません。パフォーマン スとのトレードオフになるので検討してみます。 > どちらの方法でも目的は達成できました。 > 運用面ではPostgreSQLを停止する必要の無い、誤操作時にもエラーが発生しないTRUNCATE > コマンドの方。 > 復旧の確実性ではファイル削除の方が優れている、というように感じます。 そのまとめであっています。 truncateを使う時の注意点ですが、1接続だけある状態で実行して ください。複数の接続がある状態で実行するとtruncateされたデー タを参照し続けてしまってクラッシュする可能性があります。 -- 須藤 功平 <kou****@clear*****> 株式会社クリアコード <http://www.clear-code.com/> 10周年祝いイベント： https://clear-code.doorkeeper.jp/events/48646 Groongaベースの全文検索システムを総合サポート: http://groonga.org/ja/support/ パッチ採用 - プログラミングが楽しい人向けの採用プロセス: http://www.clear-code.com/recruitment/
