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インスタンスのステータスはStorage-optimizationになります。ストレージの変更後、DBインスタンスは完全に機能します。ただし、6時間、またはDBインスタンスのステータスがストレージ最適化である間は、どちらか長い方でストレージの変更を行うことはできません。
ただし、特別なケースは、SQL Server DBインスタンスがあり、2017年11月以降にストレージ構成を変更していない場合です。この場合、DBインスタンスを変更して割り当て量を増やすと、数分の短い停止が発生する可能性がありますストレージ。停止後、DBインスタンスはオンラインになりますが、ストレージ最適化状態です。ストレージの最適化中にパフォーマンスが低下する可能性があります。
最初に、誤った操作を見ている可能性があることに注意してください-ストレージsizeを変更する必要があると説明していますが、ストレージtype。これは重要なことです。RDSでは、ストレージサイズの変更による停止は発生しないが、ストレージタイプの変更による停止は発生することをお勧めしています。
ストレージサイズを変更すると、パフォーマンスの低下が予想されます。その期間と影響は、いくつかの要因によって異なります。
- RDSインスタンスタイプ
- 構成
- これはメンテナンス中に発生しますか？
- これらの変更は、まずマルチAZスレーブで発生し、次にフェイルオーバーしますか？
- 現在のデータベースサイズ
- 候補データベースのサイズ
- リクエストされた時間帯、リクエストされたアベイラビリティーゾーン、リクエストされたリージョンでこのリクエストを処理するAWSの容量
- エンジンの種類（ Amazon Auroraユーザーの場合 、ストレージの追加は必要に応じて10 GBの増分でRDSによって管理されるため、この説明は議論の余地があります）
これを念頭に置いて、自分で、自分の環境で、自分の条件でこれをテストすることで、より良いサービスが提供されます。以下を試してみてください。
- 既存のインスタンスのスナップショットから新しいRDSインスタンスを復元し、新しいクローンでこの操作を実行します。
- このクローンの場合：
- AWSで異なる負荷が予想される時間帯にサイズを増やします。
- 異なるサイズに増やします。
- マルチAZでお試しください。マルチAZを有効にしない場合と比較して、実際のダウンタイムが変化するかどうかを確認します。
- メンテナンス期間中に試して、変更をすぐに適用する場合と比較してください。
これには少しコストがかかります（必要はありません...ほとんどの場合1〜3インスタンス時間で実行できます）が、無数の異なるRDSでの経験を行商するよりもはるかに明確な答えが得られます。環境。
それでも「球場」の答えを探している場合は、少なくとも数秒ではなく数分の範囲でパフォーマンスの低下を計画することをお勧めします。これも環境と構成に大きく依存します。
参考までに、私はこの正確な操作を最近適用して、土曜日の午後（EST）に40GBのdb.m1.smallタイプのインスタンスに10GBを追加しました。インスタンスは約17分間「変更中」の状態のままでした。変更状態は実際のダウンタイムではなく、 操作が適用されている期間 を表すことに注意してください。実際のインスタンスに追加の変更を適用することはできません（ただし、DB自体には引き続きアクセスできます）。これは、パフォーマンスの低下が予想される期間でもあります。
ストレージサイズの変更のみを計画している場合、予期しない停止が発生しますが、この変更が その他の操作 と組み合わせて行われた場合に発生する可能性があることに注意してください。 。
ストレージサイズを増やしているだけで、インスタンスタイプやその他を変更していないため、ダウンタイムは発生しませんが、操作の実行中に「パフォーマンスの低下」が発生する可能性があります。
引用された参照は、ストレージタイプの変更と同時にストレージサイズの変更についても説明しているため、あいまいです。代わりに、次の表の「割り当てられたストレージ」を確認すると、
http://docs.aws.Amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html
「パフォーマンスが低下する可能性がある」とだけ表示され、停止については何も表示されないことがわかります（ストレージタイプを切り替えると発生する場合もあります）。
参考までに、15 GBのdb.m3.medium MySQLデータベースを稼働中にeu-west-1で20 GBに変更しても、アプリとデータベースの接続は中断されませんでした。ただし、読み取り/書き込みIOPSはどちらも20分弱で400〜700/sに増加したため、パフォーマンスの低下を参照していると思います。これは、シングルAZデータベースインスタンスとマルチAZデータベースインスタンスの両方で報告されました。 （インスタンスはこれより少し長い間「変更中」と報告されました-約25分）
当然、実際のdbインスタンスで実際に実行する前に、実際のdbインスタンスで実行する前に、実際のdbインスタンスと同じdbインスタンスでそれを試すことができます。