今朝、私は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イベントは次のとおりです。
データベースCPUは08:44から10:27の間に最大になりました。この時間の多くは、アップグレード前およびアップグレード後のスナップショットを取るRDSによって占有されているように見えました。
AWSのドキュメントには、それらを読んでから、我々のアプローチの明らかな欠陥は、我々はのコピーを作成しなかったことであることは明らかであるものの、そのような影響を警告していない生産マルチAZセットアップでデータベースをし、としてそれをアップグレードしよう試運転
一般に、RDSが何をしていて、どれくらいの時間がかかる可能性があるかについて、RDSがほとんど情報を提供しなかったため、非常にイライラしていました。（繰り返しになりますが、試用版を実行すると助かります...）
それとは別に、この事件から学びたいので、ここに質問があります：
- RDSでメジャーバージョンアップグレードを行う場合、この種のことは正常ですか？
- 将来、最小のダウンタイムでメジャーバージョンアップグレードを行いたい場合、どうすればよいでしょうか？レプリケーションを使用してシームレスにするための賢い方法はありますか？
ANALYZE統計を更新するマニュアルがそれを解決しました。誰かがこれについての洞察を持っているなら、それも素晴らしいでしょう。