Amazon RDS 用のマルチ AZ DB インスタンスのフェイルオーバー
マルチ AZ DB インスタンスの計画的または計画外の停止がインフラストラクチャの欠陥に起因する場合、Amazon RDS は別のアベイラビリティーゾーンのスタンバイレプリカに自動的に切り替わります。
フェイルオーバーが完了するまでにかかる時間は、プライマリ DB インスタンスが使用できなくなったときのデータベースアクティビティおよびその他の条件によって異なります。フェイルオーバー時間は通常 60～120 秒です。ただし、大規模なトランザクションや長期にわたる復旧プロセスによって、フェイルオーバー時間が増加する場合があります。フェイルオーバーが完了してから、新しいアベイラビリティーゾーンが RDS コンソールに反映されるまでさらに時間がかかる場合があります。
注記
マルチ AZ DB インスタンスを再起動するときに手動でフェイルオーバーを強制的に実行することができます。詳細については、「 DB インスタンスの再起動」を参照してください。
Amazon RDS はフェイルオーバーを自動的に処理するため、管理者が操作しなくても可能な限りすみやかにデータベース操作を再開できます。次の表に記載されている条件のいずれかが発生した場合、プライマリ DB インスタンスがスタンバイレプリカに自動的に切り替わります。これらのフェイルオーバーの理由は、イベントログで確認できます。
| フェイルオーバーした理由 | 説明 |
|---|---|
RDS データベースインスタンスの基盤となるオペレーティングシステムには、オフライン操作でパッチが適用されています。 |
OS パッチまたはセキュリティ更新プログラムのメンテナンス期間中に、フェイルオーバーがトリガーされました。 詳細については、「DB インスタンスのメンテナンス」を参照してください。 |
RDS マルチ AZ インスタンスのプライマリホストが異常です。 |
マルチ AZ DB インスタンスのデプロイは、障害のあるプライマリ DB インスタンスを検出し、フェイルオーバーしました。 |
RDS マルチ AZ インスタンスのプライマリホストで、ネットワーク接続が切断されたため、到達できません。 |
RDS モニタリングは、プライマリ DB インスタンスへのネットワーク到達可能性による障害を検出し、フェイルオーバーをトリガーしました。 |
RDS インスタンスはお客様によって変更されました。 |
RDS DB インスタンスの変更により、フェイルオーバーがトリガーされました。 詳細については、「Amazon RDS DB インスタンスを変更する」を参照してください。 |
RDS マルチ AZ プライマリインスタンスはビジーで応答しません。 |
プライマリ DB インスタンスが応答しません。次のことを行うことをお勧めします。
これらの推奨事項の詳細については、Amazon RDS のモニタリングツール および Amazon RDS のベストプラクティス を参照してください。 |
RDS マルチ AZ インスタンスのプライマリホストの基盤となるストレージボリュームでエラーが発生しました。 |
マルチ AZ DB インスタンスのデプロイは、プライマリ DB インスタンスでストレージの問題を検出し、フェイルオーバーしました。 |
ユーザーが DB インスタンスのフェイルオーバーをリクエストしました。 |
DB インスタンスを再起動し、[Reboot with failover (フェイルオーバーで再起動)] を選択しました。 (詳しくは、「 DB インスタンスの再起動」を参照してください。) |
マルチ AZ DB インスタンスがフェイルオーバーされたかどうかを判断するには、次を実行します。
フェイルオーバーがスタートされたことを電子メールまたはSMSで通知するようにDBイベントサブスクリプションを設定します。 イベントの詳細については、「Amazon RDS イベント通知の操作」を参照してください。
RDS コンソールまたは API オペレーションを使用して DB イベントを表示します。
RDS コンソールまたは API オペレーションを使用して、マルチ AZ DB インスタンスのデプロイの現在の状態を表示します。
フェイルオーバーへの応答、復旧時間の短縮、Amazon RDS のその他のベストプラクティスについては、「Amazon RDS のベストプラクティス」を参照してください。
DNS 名参照用の JVM TTL の設定
フェイルオーバーメカニズムでは、スタンバイ DB インスタンスをポイントするように DB インスタンスのドメインネームシステム (DNS) レコードが自動的に変更されます。したがって、DB インスタンスへの既存の接続の再確立が必要になります。Java 仮想マシン (JVM) 環境では、Java DNS キャッシュ機構がどのように機能するかによって、JVM 設定の再構成が必要になる場合があります。
JVM は DNS 名参照をキャッシュします。JVM がホスト名を IP アドレスに変換するとき、time-to-live (TTL) と呼ばれる指定期間 IP アドレスをキャッシュします。
AWS リソースは、ときどき変更される DNS 名を使用するため、60 秒を超えない TTL 値で JVM を設定することをお勧めします。こうすることにより、リソースの IP アドレスが変更されたときに、アプリケーションは DNS に対して再度クエリを実行することで、リソースの新しい IP アドレスを取得して使用できます。
一部の Java 設定では JVM のデフォルトの TTL が設定されるため、JVM が再起動されるまで、DNS エントリが更新されることはありません。したがって、アプリケーションがまだ実行中に AWS リソースの IP アドレスが変更された場合、JVM を手動で再起動し、キャッシュされた IP 情報が更新されるまで、そのリソースを使用することはできません。この場合、キャッシュされた IP 情報が定期的に更新されるように JVM の TTL を設定することがきわめて重要です。
JVM のデフォルト TTL は、networkaddress.cache.ttl
String ttl = java.security.Security.getProperty("networkaddress.cache.ttl");
注記
デフォルト TTL は、JVM のバージョンと、セキュリティマネージャーがインストールされているかどうかに応じて変わります。多くの JVM はデフォルト TTL を 60 秒以下にしています。このような JVM を使用しており、セキュリティマネージャーを使用していない場合、このトピックの残り部分は無視してかまいません。Oracle のセキュリティマネージャーの詳細については、Oracle ドキュメントの 「The Security Manager
JVM の TTL を変更するには、networkaddress.cache.ttl プロパティ値を設定します。ニーズに応じて、次の方法のいずれかを使用します。
-
JVM を使用するすべてのアプリケーションのプロパティ値をグローバルに設定するには、
networkaddress.cache.ttlファイルで$JAVA_HOME/jre/lib/security/java.securityを設定します。networkaddress.cache.ttl=60 -
アプリケーションに対してのみプロパティをローカルに設定するには、ネットワーク接続を確立する前に、アプリケーションの初期化コードで
networkaddress.cache.ttlを設定します。java.security.Security.setProperty("networkaddress.cache.ttl" , "60");
