Amazon RDS 用のマルチ AZ DB クラスターのフェイルオーバー
マルチ AZ DB クラスター内のライター DB インスタンスで計画的な機能停止または計画外の機能停止が発生した場合、Amazon RDS は別のアベイラビリティーゾーンのリーダー DB インスタンスに自動的にフェイルオーバーします。これにより、中断を最小限に抑えながら高可用性を確保できます。フェイルオーバーは、ハードウェア障害、ネットワークの問題、または手動リクエスト中に発生する可能性があります。このトピックでは、障害の自動検出、フェイルオーバー中のイベントのシーケンス、読み取りおよび書き込みオペレーションへの影響について説明します。また、フェイルオーバー時間をモニタリングして最小限に抑えるためのベストプラクティスも提供します。
フェイルオーバーが完了するまでにかかる時間は、データベースアクティビティや、ライターDB インスタンスが使用できなくなった時点の他の条件によって異なります。フェイルオーバーの時間は通常 35 秒未満です。フェイルオーバーは、両方のリーダー DB インスタンスが、失敗したライターからの未処理のトランザクションを適用すると完了します。フェイルオーバーが完了してから、新しいアベイラビリティーゾーンが RDS コンソールに反映されるまでさらに時間がかかる場合があります。
自動フェイルオーバー
Amazon RDS はフェイルオーバーを自動的に処理するため、管理者が操作しなくても可能な限りすみやかにデータベース操作を再開できます。フェイルオーバーするには、ライター DB インスタンスがリーダー DB インスタンスに自動的に切り替わります。
マルチ AZ DB クラスターを手動でフェイルオーバーする
マルチ AZ DB クラスターを手動でフェイルオーバーすると、RDS は最初にプライマリ DB インスタンスを終了します。次に、内部モニタリングシステムがプライマリ DB インスタンスに異常があることを検出し、読み取り可能なレプリカ DB インスタンスを昇格させます。フェイルオーバーの時間は通常 35 秒未満です。
AWS Management Console、AWS CLI、または RDS API を使用して、マルチ AZ DB クラスタを手動でフェイルオーバーできます。
マルチ AZ DB クラスターを手動でフェイルオーバーするには
AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/
) を開きます。 -
ナビゲーションペインで、データベースを選択します。
-
フェイルオーバーするマルチ AZ DB クラスターを選択します。
-
「アクション」で、「フェイルオーバー」を選択します。
[フェイルオーバー DB クラスター] ページが表示されます。
-
フェイルオーバーを選択して、手動フェイルオーバーを確認します。
マルチ AZ DB クラスターを手動でフェイルオーバーするには、AWS CLIコマンドフェイルオーバー db-クラスタを使用します。
aws rds failover-db-cluster --db-cluster-identifier
mymultiazdbcluster
マルチ AZ DB クラスターを手動でフェイルオーバーするには、Amazon RDS API FailoverDBClusterを呼び出し、DBClusterIdentifier
を指定します。
マルチ AZ DB クラスターがフェイルオーバーしたかどうかの判別
マルチ AZ DB クラスターがフェイルオーバーされたかどうかを判断するには、次を実行します。
フェイルオーバーがスタートされたことを電子メールまたはSMSで通知するようにDBイベントサブスクリプションを設定します。 イベントの詳細については、「Amazon RDS イベント通知の操作」を参照してください。
Amazon RDS コンソールまたは API オペレーションを使用して DB イベントを表示します。
Amazon RDS コンソール、AWS CLIおよび 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 を設定することがきわめて重要です。
注記
デフォルト 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");