Amazon Auroraデータベースは可用性に優れており、その高速なフェイルオーバーは売りの一つです。 Amazon Auroraの可用性に関するドキュメントによると、レプリカが1つ以上あると、フェイルオーバーによりレプリカがプライマリインスタンスに昇格し、60秒未満でフェイルオーバーが完了します。 DB クラスターに 1 つ以上の Aurora レプリカがある場合は、障害発生中に 1 つの Aurora レプリカがプライマリインスタンスに昇格されます。障害イベントによって短い中断が発生し、その間例外によって読み取りと書き込みオペレーションが失敗します。ただし、一般的なサービスの復元時間は 120 秒未満であり、多くの場合 60 秒未満で復元されます。DB クラスターの可用性を高めるために、複数のアベイラビリティーゾーン内で少なくとも 1 つ以上の Aurora レプリカを作成することを
EFSが東京リージョンで一般利用可能になって2年、実際にEFSサービスを使ってシステムを構築してみたのはここ最近で「EFSで障害が発生した時ってどうなるんだろう？フルマネージドサービスだからフェイルオーバーもよしなにやってくれるんだろう」と思って調べてみました。 構成図 ALB配下にAZ毎にEC2をそれぞれ配置し、それぞれのAZにマウントターゲットを持つEFSリソースを作成しました。ファイルシステムは、マウントターゲットであるENIを経由してアクセスできます。 EC2インスタンスは、Amazon Linux2でEFSマウントヘルパーを使ってマウントしています。 障害発生時(意図的な)の挙動 意図的に障害を発生させてみます。 まずは、セキュリティグループを変更し、tcp/2049にアクセスできない場合です。 書き込みしようとするとアクセスできない為、レスポンスが返ってきません。ターゲットのス
RDSやAuroraのフェイルオーバー などのイベント情報は、RDSマネジメントコンソールやAWS CLIで確認コマンドを実行するなどで表示が可能です。 ただ、重要なイベントの発生はできるだけ早く検知したいと思うものです。 今回は、RDSのイベントサブスクリプション機能を使って、フェイルオーバーが発生した際にEメールで通知する設定方法を紹介します。 なんと、作業時間はたったの約5分!お手軽に設定できました。 前提条件 目的は、「指定されたDBクラスター でフェイルオーバー が発生したら、メールで通知を行う」です。 参照ドキュメント 下記のAWSドキュメントに記載されている手順を参考に、設定していきます。 一見、ドキュメントにはRDSの設定について書かれているようにも思えますが、Aurora クラスターも同様の手順で通知を設定できます。 検証環境 本記事では、通知対象のDBは作成済みの前提で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
