RDSインスタンスのスケールアップ

RDSインスタンスのスケールアップをします。
前提として当該RDSは、Multi-AZ で稼働しています。Multi-AZの場合はフェイルオーバーしながらスケールアップし、サービス停止時間を最小限に抑えることができます。

1. まず、バックアップとして当該RDSのスナップショットを取得しておきます。

 

2. スケールアップするRDSインスタンスを選択し、右クリックメニューの「変更」をクリック

3. 「DBインスタンスのクラス」でスケールアップするインスタンスを選択します。(以下の場合は、db.t2.large へスケールアップします)

4. 「すぐに適用」をチェックし、画面下の「次へ」をクリックします。

5. 変更内容を確認して「DB インスタンスの変更」をクリックします。

6. すると、DBインスタンスのステータスが「変更中」になります。

7. 変更が終わると「利用可能」になり、セカンダリゾーンがスケールアップ前のプライマリのアベイラビリティゾーンのものに変わっていることから、フェイルオーバーされたと判断できます。

8. イベントログを見るとフェイルオーバーしていることが確認できます。

これを見ると、10分弱でセカンダリのスケールアップが終了し、フェイルオーバーに40秒程度、その後、もう一方のスケールアップに6分程かかっていることがわかります。
サービス停止時間としては、30秒~40秒程度ということになるかと思います。(もちろん、データ容量等で変わってくるかと思います)

9. 以上でRDSのスケールアップ自体は完了ですが、フェイルオーバーしているのでプライマリのAZが変わり、RDSに接続するEC2と異なるAZになりますので、レイテンシーが心配です。
一応、AWSのQAには大丈夫そうなこと書いていますが、切り戻しを行いたいと思います。(わかりにくい文章だ)

10. フェイルオーバーしたMulti-AZ のRDSを切り戻すにはRDSインスタンスを再起動します。該当のRDSインスタンスを選択し、右クリックメニューから「再起動」を選びます。

11. 開いたダイアログの「フェイルオーバーし再起動しますか?」をチェックを入れて「再起動」ボタンを押します。

12. イベントログでは、再起動時にフェイルオーバーしていることが確認できます。

13. 当該RDSインスタンスの詳細情報にて、セカンダリゾーンが当初のAZになっているのが確認できます。

14. プライマリのゾーンも当初のものでEC2と同じAZになっていることが確認できます。

これで、スケールアップ、フェイルオーバーの切り戻し作業の終了です。
サービス停止時間は、フェイルオーバーの40秒×2回 といったところでしょうか?

 

 

スポンサーリンク

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です