一時的にMulti-AZにしてフェイルオーバーしたRDSのAvailability Zoneを元にもどす一番簡単な方法（TGI Multi-AZ Pattern） - サーバーワークスエンジニアブログ
こんにちは、顔抜きジャーナリストのアカツカです。 私はサーバーワークス東北リージョン担当で、普段はクラウドの恩恵をフルに受けて山形や仙台を中心にリモート勤務をしています。 「クラウドで、東北を、もっと、はたらきやすく。」をモットーに活動しておりますので、どうぞよろしくお願いいたします。 なお、「顔抜きジャーナリスト」が何か知りたい方は、ぜひAWSのユーザーイベントにご参加下さい。 さて、AWSの計画メンテナンスでRDSインスタンスの再起動が行われる場合、別々のデータセンター間で同期レプリケーションされたMulti-AZ構成ではなく、単一拠点でのSingle-AZで運用していると、再起動中はサービスが停止してしまうことがありますよね。 せっかくクラウドを活用しても、これでは可用性の面でオンプレミスの時と変わりありません。 しかしAWSでは一時的にSingle-AZからMulti-AZに切り替
【AWS】RDSのインスタンスタイプ変更にかかる時間を調べてみた | DevelopersIO
はじめに こんにちは植木和樹です。AWSでEC2と並んでよく使われているサービスがRDSだと思います。障害時のフェイルオーバーやバックアップも自動で行ってくれるため、データベースを手間をかけずに利用することができ本当に便利なサービスです。 さてRDSを用いたサービスをリリースしてしばらく経つと、徐々にCPUやメモリなどの使用率が増えていき、いよいよインスタンスタイプの見直しを検討しなければならなくなるかと思います。その時に気になるのが「インスタンスタイプ変更にはどれくらい時間がかかるのか？」「サービスの停止が必要なのか？」という点です。 本日はSingle-AZ/Multi-AZそれぞれのRDSについて、インスタンスタイプの変更にかかる時間や挙動を調べてみました。 今回のブログに記載したインスタンスタイプ変更の流れは、AWS公式のものでなくイベントログやDBの動きから筆者個人が「おそらくこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
