今朝、私はAWS RDS上のPostgreSQLデータベースのアップグレードに関与しました。バージョン9.3.3からバージョン9.4.4に移行したかったのです。ステージングデータベースでアップグレードを「テスト」しましたが、ステージングデータベースはどちらもはるかに小さく、マルチAZを使用していません。このテストはかなり不十分であることがわかりました。
本番データベースはマルチAZを使用しています。過去にマイナーバージョンのアップグレードを行ったことがあります。その場合、RDSは最初にスタンバイをアップグレードしてから、マスターに昇格します。したがって、発生する唯一のダウンタイムは、フェイルオーバー中に約60秒です。
メジャーバージョンのアップグレードでも同じことが起こると想定していましたが、なんと間違っていました。
セットアップに関する詳細:
アップグレードの実行中にログに記録されたRDSイベントは次のとおりです。
データベースCPUは、約08:44と10:27の間で最大になりました。この時間の多くは、アップグレード前とアップグレード後のスナップショットをとるRDSによって占有されているようです。
AWS docs このような影響については警告しませんが、それらを読むと、私たちのアプローチの明らかな欠陥は、productionデータベースをマルチAZ設定で試して、アップグレードを試みます
一般に、RDSが何をしているか、どのくらい時間がかかるかについての情報がほとんどないため、非常にイライラしました。 (繰り返しになりますが、試運転をすると助かります...)
それとは別に、私たちはこの事件から学びたいので、ここに私たちの質問があります:
これは良い質問です
クラウド環境での作業は時々トリッキーです。
pg_dumpall -f dump.sql
コマンドを使用して、データベース全体をSQLファイル形式にダンプします。他のエンドポイントをポイントして最初からデータベースを再構築することができます。略してpsql -h endpoint-Host.com.br -f dump.sql
を使用します。
しかし、それを行うには、(データベースダンプに合わせるために)ディスクに適切なスペースを持つEC2インスタンスが必要になります。また、ダンプおよび復元コマンドを実行できるようにするには、yum install postgresql94.x86_64
をインストールする必要があります。
PG Dumpall DOC の例を参照してください。
データの整合性を保つために、このメンテナンス期間中にデータベースに接続するシステムをシャットダウンすることをお勧めします(場合によっては必須になります)。
また、処理を高速化する必要がある場合は、並列処理(pg_dump
)パラメータを利用して、プロセスに関与するCPUの数を決定するときに、pg_dumpall
ではなく-j njobs
を使用することを検討してください。例-j 8
は8 CPUまで使用します。デフォルトでは、pg_dumpall
またはpg_dump
の動作は1のみを使用します。代わりにpg_dump
を使用することによる唯一の利点は、pg_dumpall
は、データベースごとにコマンドを実行する必要があることです。あり、ROLES(グループとユーザー)を分離してダンプします。
PG Dump DOC および PG Restore DOC の例を参照してください。