web-dev-qa-db-ja.com

AWS RDS postgresデータベースのメジャーバージョンをシームレスにアップグレードするにはどうすればよいですか?

今朝、私はAWS RDS上のPostgreSQLデータベースのアップグレードに関与しました。バージョン9.3.3からバージョン9.4.4に移行したかったのです。ステージングデータベースでアップグレードを「テスト」しましたが、ステージングデータベースはどちらもはるかに小さく、マルチAZを使用していません。このテストはかなり不十分であることがわかりました。

本番データベースはマルチAZを使用しています。過去にマイナーバージョンのアップグレードを行ったことがあります。その場合、RDSは最初にスタンバイをアップグレードしてから、マスターに昇格します。したがって、発生する唯一のダウンタイムは、フェイルオーバー中に約60秒です。

メジャーバージョンのアップグレードでも同じことが起こると想定していましたが、なんと間違っていました。

セットアップに関する詳細:

  • db.m3.large
  • プロビジョンドIOPS(SSD)
  • 300 GBストレージ、そのうち139 GBが使用されます
  • 優れたRDS OSアップグレードがあり、このアップグレードとバッチ処理してダウンタイムを最小限に抑えたかった

アップグレードの実行中にログに記録されたRDSイベントは次のとおりです。

enter image description here

データベースCPUは、約08:44と10:27の間で最大になりました。この時間の多くは、アップグレード前とアップグレード後のスナップショットをとるRDSによって占有されているようです。

AWS docs このような影響については警告しませんが、それらを読むと、私たちのアプローチの明らかな欠陥は、productionデータベースをマルチAZ設定で試して、アップグレードを試みます

一般に、RDSが何をしているか、どのくらい時間がかかるかについての情報がほとんどないため、非常にイライラしました。 (繰り返しになりますが、試運転をすると助かります...)

それとは別に、私たちはこの事件から学びたいので、ここに私たちの質問があります:

  • RDSでメジャーバージョンのアップグレードを行う場合、このようなことは正常ですか?
  • ダウンタイムを最小限に抑えて、将来的にメジャーバージョンアップグレードを実行したい場合、どうすればよいでしょうか?レプリケーションを使用してそれをよりシームレスにする何らかの賢い方法はありますか?
13
jonleighton

これは良い質問です
クラウド環境での作業は時々トリッキーです。

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 の例を参照してください。

4
Vinnix