RDS Custom for Oracle マルチ AZ 配置のフェイルオーバープロセス - Amazon Relational Database Service

RDS Custom for Oracle マルチ AZ 配置のフェイルオーバープロセス

DB インスタンスの計画的または計画外の停止がインフラストラクチャの欠陥に起因する場合、マルチ AZ を有効にしていると、Amazon RDS は別のアベイラビリティーゾーンのスタンバイレプリカに自動的に切り替わります。     フェイルオーバーが完了するまでにかかる時間は、プライマリ DB インスタンスが使用できなくなったときのデータベースアクティビティおよびその他の条件によって異なります。フェイルオーバー時間は通常 60~120 秒です。ただし、大規模なトランザクションや長期にわたる復旧プロセスによって、フェイルオーバー時間が増加する場合があります。フェイルオーバーが完了してから、新しいアベイラビリティーゾーンが Amazon RDS コンソールに表示されるまでさらに時間がかかる場合があります。

注記

DB インスタンスが使用可能である間にプライマリ EC2 ホストを停止および起動すると、フェイルオーバーを手動で強制できます。

Amazon RDS はフェイルオーバーを自動的に処理するため、管理者が操作しなくても可能な限りすみやかにデータベース操作を再開できます。次の表に記載されている条件のいずれかが発生した場合、プライマリ DB インスタンスがスタンバイレプリカに自動的に切り替わります。これらのフェイルオーバーの理由は、Amazon RDS イベントログで確認できます。

フェイルオーバーした理由 説明
RDS データベースインスタンスの基盤となるオペレーティングシステムには、オフライン操作でパッチが適用されています。 OS パッチまたはセキュリティ更新プログラムのメンテナンス期間中に、フェイルオーバーがトリガーされました。詳細については、「DB インスタンスのメンテナンス」を参照してください。
RDS マルチ AZ インスタンスのプライマリホストが異常です。 マルチ AZ DB インスタンスのデプロイは、障害のあるプライマリ DB インスタンスを検出し、フェイルオーバーしました。
RDS マルチ AZ インスタンスのプライマリホストで、ネットワーク接続が切断されたため、到達できません。 RDS モニタリングは、プライマリ DB インスタンスへのネットワーク到達可能性による障害を検出し、フェイルオーバーをトリガーしました。
RDS インスタンスはお客様によって変更されました。 RDS DB インスタンスの変更により、フェイルオーバーがトリガーされました。詳細については、「RDS Custom for Oracle DB インスタンスを変更する」を参照してください。
RDS マルチ AZ インスタンスのプライマリホストの基盤となるストレージボリュームでエラーが発生しました。 マルチ AZ DB インスタンスのデプロイは、プライマリ DB インスタンスでストレージの問題を検出し、フェイルオーバーしました。
RDS マルチ AZ プライマリインスタンスはビジーで応答しません。 プライマリ DB インスタンスが応答しません。以下の実施をお勧めします。イベントログと CloudWatch ログを調べて、CPU、メモリ、またはスワップ領域の使用量が多すぎるかどうかを調べます。詳細については、「Amazon RDS イベント通知の操作」および「Amazon RDS イベントでトリガーするルールの作成」を参照してください。ワークロードを評価して、適切な DB インスタンスクラスを使用しているかどうかを判断します。詳細については、「 DB インスタンスクラス」を参照してください。

マルチ AZ DB インスタンスがフェイルオーバーされたかどうかを判断するには、次を実行します。

  • フェイルオーバーがスタートされたことを電子メールまたはSMSで通知するようにDBイベントサブスクリプションを設定します。 イベントの詳細については、「Amazon RDS イベント通知の操作」を参照してください。

  • Amazon RDS コンソールまたは API オペレーションを使用して DB イベントを表示します。

  • Amazon RDS コンソール、CLI、または API オペレーションを使用して、RDS Custom for Oracle Multi-AZ DB インスタンスのデプロイの現在の状態を表示します。

RDS Custom for Oracle マルチ AZ 配置を使用するアプリケーションでの Time to live (TTL) 設定

フェイルオーバーメカニズムでは、スタンバイ DB インスタンスをポイントするように DB インスタンスのドメインネームシステム (DNS) レコードが自動的に変更されます。したがって、DB インスタンスへの既存の接続の再確立が必要になります。DNS キャッシュ Time to live (TTL) 設定値が低いことを確認し、アプリケーションが DNS を長期間キャッシュしないことを確認します。TTL 値が高いと、フェイルオーバー後にアプリケーションが DB インスタンスにすぐに再接続できなくなる可能性があります。