AWS RDSストレージを増やすためのダウンタイム？

2つのRDSインスタンスのストレージを増やすことを検討しています（インスタンスタイプやその他のパラメーターではなく、割り当てられたストレージスペースのみ）。https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html#USER_PIOPS.ModifyingExistingのドキュメントは以下を示唆しています。

標準ストレージからプロビジョンドIOPSストレージ、またはプロビジョンドIOPSから標準ストレージに変更したり、ダウンタイムをほとんどまたはまったくせずにストレージを増やしたりできます。

変更を実行する前に、メンテナンスウィンドウを必ずスケジュールします。しかし、ドキュメントはこの領域では少しあいまいに見えます。これを以前に行ったことのある人にとって、「ダウンタイムがほとんどない」とは何ですか？5秒を期待できますか、それとも5分に近いですか？

2019年7月の更新：

正しい更新されたAWSドキュメントへのリンクを更新しました（破損していました）。新しいドキュメントには、元の質問に答えるのに役立つ宣伝文句があります。

ほとんどの場合、ストレージのスケーリングは停止を必要とせず、サーバーのパフォーマンスを低下させません。DBインスタンスのストレージサイズを変更すると、DBインスタンスのステータスはストレージ最適化になります。ストレージ変更後、DBインスタンスは完全に動作可能になります。ただし、6時間またはDBインスタンスのステータスがストレージ最適化のいずれか長い方の期間、ストレージをさらに変更することはできません。

ただし、特殊なケースは、SQL Server DBインスタンスがあり、2017年11月以降ストレージ構成を変更していない場合です。この場合、DBインスタンスを変更して割り当てられた値を増やすと、数分間の短い停止が発生する可能性がありますストレージ。停止後、DBインスタンスはオンラインですが、ストレージ最適化状態にあります。ストレージの最適化中にパフォーマンスが低下する場合があります。

まず、誤った操作を見ている可能性があることに注意してください。ストレージサイズを変更したいが、ストレージタイプを説明したドキュメントを引用していることを説明します。これは重要な矛盾です。RDSは、ストレージサイズを変更しても停止することはないが、ストレージタイプを変更すると停止することをお勧めします。

ストレージサイズを変更するとパフォーマンスの低下が予想されますが、その期間と影響はいくつかの要因に依存します。

• RDSインスタンスタイプ
• 構成
  • これはメンテナンス中に発生しますか？
  • これらの変更は最初にマルチAZスレーブで発生し、次にフェイルオーバーしますか？
• 現在のデータベースサイズ
• 候補データベースのサイズ
• リクエストされた時間帯、リクエストされたアベイラビリティーゾーン、リクエストされたリージョンでこのリクエストを処理するAWSの能力
• エンジンタイプ（Amazon Auroraユーザーの場合、ストレージの追加は必要に応じて10 GB単位でRDSによって管理されるため、この議論は重要ではありません）

これを念頭に置いて、あなた自身で、あなたの環境で、そしてあなたの条件でこれをテストすることにより、あなたはより良いサービスを受けるでしょう。以下を試してみてください。

• 既存のインスタンスのスナップショットから新しいRDSインスタンスを復元し、新しいクローンでこの操作を実行します。
• このクローンでは：
  • AWSに異なる負荷がかかると予想される1日のさまざまな時間にサイズを増やします。
  • さまざまなサイズに増やします。
  • マルチAZで試してください。マルチAZを有効にしない場合と比較して、実際のダウンタイムが変化するかどうかを確認します。
  • メンテナンス期間中に試してみて、すぐに変更を適用することと比較してください。

これにはもう少し費用がかかります（1〜3インスタンス時間で大部分を行うことができます）。環境。

まだ「球場」の答えを探している場合は、少なくともパフォーマンスの低下を数秒ではなく数分で計画することをお勧めします。これも環境と構成に大きく依存します。

参考までに、私は最近、この正確な操作を適用して、土曜日の午後（EST）に40GB db.m1.smallタイプのインスタンスに10GBを追加しました。インスタンスは約17分間「変更」状態のままでした。変更中の状態は実際のダウンタイムではなく、操作が適用されている期間を示していることに注意してください。実際のインスタンスに追加の変更を適用することはできません（ただし、DB自体にアクセスすることはできます）。これは、パフォーマンスの低下が予想される期間でもあります。

ストレージサイズの変更のみを計画している場合は、予期しない停止が発生しますが、この変更がインスタンス識別子/クラスまたはストレージタイプの変更などの他の操作と一緒に行われた場合に発生する可能性があります。

ストレージサイズを増やしているだけで、インスタンスタイプなどを変更していないため、ダウンタイムは発生しませんが、操作の実行中に「パフォーマンスの低下」が発生する可能性があります。

引用した引用文献はあいまいです。なぜなら、ストレージサイズの変更と同時にストレージタイプの変更についても議論しているからです。代わりに、この表の「割り当てられたストレージ」を見ると：

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html

「パフォーマンスが低下する可能性がある」とだけ表示され、停止については何も表示されないことがわかります（ストレージタイプの切り替え時に発生することがあります）。

参考までに、営業日中にeu-west-1で15GB db.m3.medium MySQLデータベースを20GBに変更しても、データベースへのアプリの接続は中断されませんでした。ただし、読み取り/書き込みIOPSは両方とも20分弱で400〜700 / sの間に増加したため、パフォーマンスの低下を参照していると思われます。これは、シングルAZデータベースインスタンスとマルチAZデータベースインスタンスの両方で報告されました。（インスタンスはこれより少し長い間、「変更中」と報告されました-約25分）

当然、実稼働DBインスタンスで実行する前に実稼働DBと同一のDBインスタンスで試してみて、実際に実行する前に状況でどのように動作するかを安全に確認できます。