Postgresql DB移行

インフラの見直しに伴いDB移行を行う事になりましたが、フルダンプの移行だと数日かかることが判明した為、いくつか時間短縮の施策を検討してみました。

移行環境

（移行前）
postgresql8.3.5
※移行前の容量は400G程度
（移行後）
postgresql9.3.5

施策１

まず、フルダンプの移行をやめて、テーブル単位の移行に変更しました。また、テーブルの中でも、変更が発生しないマスター系のテーブルと、変更が発生するトランザクション系のテーブルを精査して、マスター系のテーブルは事前移行する事にし、トランザクション系のテーブルのみをサービス停止して移行する事にしました。
後、トランザクション系のテーブルは、移行の必要が無い不要レコードを出来る限り削除しました。

施策２

「施策１」を実施して、再度移行時間を計測してみましたが、それでも数十時間かかることが判明しました。そこで、その中でも移行に時間がかかるテーブルに着目し、時間短縮できないか検討してみました。

施策3

「施策２」で、エクスポート/インポート/index作成等を細分化して計測してみた所、インデックス作成に時間が掛かっていることが分かりました。
そこで、index作成を高速化できないか調べてみた所、DBのパラータ[maintenance_work_mem]を増やすことで高速化できることが分かりました。
https://www.postgresql.jp/document/9.3/html/populate.html

また、postgresqlの移行高速化方法を調べていく中で、WALの書き込み停止(full_page_writes=false/fsync=false)、pg_dump/pg_restoreを並列で実行するオプション[jobs]が有効であることも分かりました。
WALの書き込み停止
https://www.postgresql.jp/document/9.3/html/runtime-config-wal.html

並列で実行するオプション[jobs]
https://www.postgresql.jp/document/9.3/html/app-pgrestore.html
https://www.postgresql.jp/document/9.3/html/app-pgdump.html

移行リハーサル

「施策３」を一通り実装し移行リハーサルを実施した所、エクスポート/インポートトータルで10時間以内で終える事ができました。
本内容を踏まえ、本番移行の準備を行いました。

本番移行

本番当日、サービス停止している事を考慮し[maintenance_work_mem][jobs]のパラメータの値を増やして実施しました。
エクスポート迄は[jobs]のパラメータの値を増やした影響で、スケジュールより前倒しで完了しました。ところが、インポートの処理が、予定より数時間遅延しました。
原因としては、[maintenance_work_mem]の値を増やしすぎたことにより、swapが発生した事が考えられます。

最後に

スケジュールは遅延しましたが、何度かリハーサルを行っていたので、ある程度の遅延時間の予測が立てれた為、切り戻しを実施せず完了する事が出来ました。改めて、リハーサルの重要性を感じました。