高見 直輝
takam****@orega*****
2016年 7月 1日 (金) 14:17:38 JST
高見です。 以前（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のインデックスに対する条件指定が無視されているように見える 次に、PGROONGAを使用しているテーブルが複数ある状態で、その中の１つだけ インデックス再構築を実行し、そのテーブルに対して上記の各種操作を行ったと ころ、全ての操作において問題は発生しませんでした。 ●PGROONGAのTRUNCATEコマンドの利用 １．PGROONGAのtable_listコマンドで内部テーブル名一覧を取得 ２．１の一覧内のSourcesXXXテーブルに対してPGROONGAのTRUNCATコマンドを実行 ３．インデックス再構築 ２と３の間にファイル全削除のときと同様の検証を行ったところ、全ての操作でエラーが 発生しなかった。 ただ、次の4ファイルが3を実行しても更新されなかった。 pgrn pgrn.0000000 pgrn.001 pgrn.conf これらのファイルが破損した場合、この方法で100%復旧出来るかどうかは不明。 どちらの方法でも目的は達成できました。 運用面ではPostgreSQLを停止する必要の無い、誤操作時にもエラーが発生しないTRUNCATE コマンドの方。 復旧の確実性ではファイル削除の方が優れている、というように感じます。 ----------------------------- 高見 直輝 <takam****@orega*****> 株式会社オレガ TEL:03-3267-0150 FAX:03-3267-0180
