リージョンとバージョンの可用性インスタンスクラスの可用性マルチAZ DB クラスターの概要マルチ AZ DB クラスターの制限事項 AWS Management Consoleを使用したマルチ AZ DB クラスターの管理マルチ AZ DB クラスターのパラメータグループの操作レプリカの遅延とマルチ AZ DB クラスターマルチ AZ DB クラスターのフェイルオーバープロセス

マルチ AZ DB クラスター配置

あるマルチ AZ DB クラスターの配置は、2 つの読み取り可能なスタンバイ DB インスタンスを持つ Amazon RDS の準同期の高可用性の配置モードです。マルチ AZ DB クラスターには、同じAWSのリージョンに 3 つの別々のアベイラビリティーゾーンに 1 つのライター DB インスタンスと 2 つのリーダー DB インスタンスがあります。マルチ AZ DB クラスターは、マルチ AZ DB インスタンスの配置と比較して、高可用性、読み取りワークロードの容量の増加、および書き込みレイテンシーの低減を提供します。

ダウンタイムを短縮して Amazon RDS MariaDB または MySQL データベースにデータをインポートするの説明に従って、オンプレミスデータベースからマルチ AZ DB クラスターにデータをインポートできます。

マルチ AZ DB クラスターのリザーブド DB インスタンスを購入できます。詳細については、「マルチ AZ DB クラスターのリザーブド DB インスタンス」を参照してください。

トピック

重要

マルチ AZ DB クラスターは Aurora DB クラスターと同じではありません。Aurora DB クラスターの情報については、Amazon Aurora ユーザーガイドを参照してください。

リージョンとバージョンの可用性

機能の可用性とサポートは、各データベースエンジンの特定のバージョン、および AWS リージョンによって異なります。マルチ AZ DB クラスターを使用した Amazon RDS のバージョンとリージョンの可用性の詳細ついては、「マルチ AZ DB クラスター」を参照してください。

インスタンスクラスの可用性

マルチ AZ DB クラスターのデプロイは、DB インスタンスクラスのサブセットでサポートされています。サポートされているデータベースインスタンスクラスのリストについては、マルチ AZ DB クラスターを作成するための設定の「DB インスタンスクラス」を参照してください。

DB インスタンスクラスの詳細については、「 DB インスタンスクラス」を参照してください。

マルチAZ DB クラスターの概要

マルチ AZ DB クラスターでは、Amazon RDS は DB エンジンのネイティブレプリケーション機能を使用して、ライター DB インスタンスから両方のリーダー DB インスタンスにデータを複製します。ライター DB インスタンスに変更が加えられると、各リーダー DB インスタンスに送信されます。

マルチ AZ DB クラスター配置では、準同期レプリケーションを使用します。変更をコミットするには、少なくとも 1 つのリーダー DB インスタンスからの承認が必要です。イベントが完全に実行され、すべてのレプリカでコミットされたことを確認する必要はありません。

リーダー DB インスタンスは自動フェイルオーバーターゲットとして機能し、読み取りトラフィックを処理してアプリケーションの読み取りスループットを向上させます。　　　　　　ライター DB インスタンスで機能停止が発生した場合、RDS はリーダー DB インスタンスのうち 1 つへのフェイルオーバーを管理します。RDS は、最新の変更記録があるリーダー DB インスタンスを基にこれを実行します。

次の図は、マルチ AZ DB クラスターを示しています。

マルチ AZ DB クラスターは、マルチ AZ DB インスタンスの配置と比較して、通常、書き込みレイテンシーが少なくなります。また、リーダー DB インスタンスで読み取り専用ワークロードを実行することもできます。RDS コンソールには、ライター DB インスタンスのアベイラビリティーゾーンとリーダー DB インスタンスのアベイラビリティーゾーンが表示されます。また、 describe-db-clustersCLI コマンドまたはこの情報を見つけるためのDescribeDBClustersAPI オペレーションを使用することもできます。

重要

RDS for MySQL マルチ AZ DB クラスターのレプリケーションエラーを防ぐため、すべてのテーブルにプライマリキーを設定することを強くお勧めします。

マルチ AZ DB クラスターの制限事項

マルチ AZ DB クラスターには、次の制限事項が適用されます。

マルチ AZ DB クラスターは、プロビジョンド IOPS ストレージのみをサポートします。
シングル AZ DB インスタンスデプロイまたはマルチ AZ DB インスタンスデプロイをマルチ AZ DB クラスターに変更することはできません。代わりに、シングル AZ DB インスタンスデプロイまたはマルチ AZ DB インスタンスデプロイのスナップショットをマルチ AZ DB クラスターに復元することができます。
マルチ AZ DB クラスターデプロイをシングル AZ DB インスタンスまたはマルチ AZ DB インスタンスに変更することはできません。代わりに、マルチ AZ DB クラスターデプロイのスナップショットをシングル AZ DB インスタンスデプロイまたはマルチ AZ DB インスタンスデプロイに復元することができます。
マルチ AZ DB クラスターは DB インスタンスレベルでの変更をサポートしていません。これは、すべての変更は DB クラスターレベルで行われるためです。
RDS for MySQL マルチ AZ DB クラスターは、ソースで GTID が有効になっている場合にのみ、外部 MySQL ソースからのレプリケーションをサポートします。詳細については、「mysql.rds_set_external_master_with_auto_position」を参照してください。位置ベースのバイナリログレプリケーションはサポートされていません。
マルチ AZ DB クラスターでは、次の機能はサポートされていません。
- Amazon RDS Proxy
- IPv6 接続のSupport（デュアルスタックモード）
- クロスリージョン自動バックアップ
- マルチ AZ DB クラスタースナップショットデータを Amazon S3 バケットにエクスポートする
- IAM DB authentication
- Kerberos 認証
- ポートの変更
  
  別の方法として、マルチ AZ DB クラスターを特定の時点に復元し、別のポートを指定することもできます。
- オプショングループ
- 削除されたクラスターのポイントインタイムリカバリ (PITR)
- リザーブド DB インスタンス
- マルチ AZ DB クラスタースナップショットを Amazon S3 バケットから復元する
- 割り当てられる最大ストレージを設定してストレージのオートスケーリング
  
  または、ストレージを手動でスケールすることもできます。
- DBクラスターの停止とスタート
- マルチ AZ DB クラスターのスナップショットをコピーする
- 暗号化されていないマルチ AZ DB クラスターを暗号化する
RDS for MySQL マルチ AZ DB クラスターは、外部ターゲットデータベースへの複製をサポートしていません。
RDS for MySQL マルチ AZ DB クラスターでは、次のシステムストアドプロシージャのみがサポートされています。
- mysql.rds_rotate_general_log
- mysql.rds_rotate_slow_log
- mysql.rds_show_configuration
- mysql.rds_set_external_master_with_auto_position
RDS for MySQL マルチ AZ DB クラスターでは、その他のストアドプロシージャはサポートされていません。これらの手順については、「RDS for MySQL ストアドプロシージャリファレンス」を参照してください。
RDS for PostgreSQL マルチ AZ DB クラスターは、次の PostgreSQL エクステンションをサポートしていません。aws_s3、pg_transport、およびpglogical。
RDS for PostgreSQL マルチ AZ DB クラスターは、アウトバウンドネットワークアクセスでのカスタム DNS サーバーの使用をサポートしていません。

AWS Management Consoleを使用したマルチ AZ DB クラスターの管理

マルチ AZ DB クラスターは、コンソールで管理できます。

コンソールでマルチ AZ DB クラスターを管理するには

AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
ナビゲーションペインで、「データベース」を選択して、管理したいマルチ AZ DB クラスターを選択します。

次のイメージは、コンソール内のマルチ AZ DB クラスターを示しています。

使用可能なアクションアクションメニューは、マルチ AZ DB クラスターが選択されているか、クラスター内の DB インスタンスが選択されているかによって異なります。

マルチ AZ DB クラスターを選択して、クラスターの詳細を表示し、クラスターレベルでアクションを実行します。

AWS Management Consoleのマルチ AZ DB クラスターアクション

マルチ AZ DB クラスター内の DB インスタンスを選択して、DB インスタンスの詳細を表示し、DB インスタンスレベルでアクションを実行します。

AWS Management Consoleのマルチ AZ DB クラスター内の DB インスタンスのアクション

マルチ AZ DB クラスターのパラメータグループの操作

マルチ AZ DBクラスターでは、DB クラスターパラメータグループは、マルチ AZ DB クラスター内のすべての DB インスタンスに適用されるエンジン構成値のコンテナーとして機能します。

マルチ AZ DB クラスターでは、DB パラメータグループは、DB エンジンおよび DB エンジンバージョンのデフォルトの DB パラメータグループに設定されています。DB クラスターパラメータグループの設定は、クラスター内のすべての DB インスタンスに使用されます。

パラメータグループの詳細については、「パラメータグループを使用する」を参照してください。

レプリカの遅延とマルチ AZ DB クラスター

レプリカの遅延とは、ライター DB インスタンスの最新のトランザクションと、リーダー DB インスタンスで最後に適用されたトランザクションとの時間の差です。Amazon CloudWatch メトリクス ReplicaLag は、この時間の差を表します。CloudWatch のメトリクスの詳細については、「Amazon CloudWatch を使用した Amazon RDS メトリクスのモニタリング」を参照してください。

マルチ AZ DB クラスターでは高い書き込みパフォーマンスが得られますが、エンジンベースのレプリケーションの性質上、レプリカの遅延が発生する可能性があります。フェイルオーバーでは、新しいライター DB インスタンスに昇格する前にまずレプリカの遅延を解決する必要があるため、レプリカの遅延のモニタリングおよび管理は考慮事項です。

RDS for MySQL マルチ AZ DB クラスターの場合、フェイルオーバーの時間は残りの両方のリーダー DB インスタンスのレプリカの遅延によって異なります。どちらのリーダー DB インスタンスについても、いずれかが新しいライター DB インスタンスに昇格する前に、未適用のトランザクションを適用する必要があります。

RDS for PostgreSQL マルチ AZ DB クラスターの場合、フェイルオーバーの時間は残りの 2 つのリーダー DB インスタンスの最も低いレプリカの遅延によって異なります。レプリカの遅延が最も低いリーダー DB インスタンスについては、新しいライター DB インスタンスに昇格する前に、未適用のトランザクションを適用する必要があります。

レプリカの遅延が設定された時間を超過した際に CloudWatch アラームを作成する方法のチュートリアルについては、「チュートリアル: マルチ AZ DB クラスターレプリカラグ用の Amazon CloudWatch アラームを作成する」を参照してください。

レプリカの遅延の一般的な原因

一般に、レプリカの遅延は書き込みワークロードが高すぎてリーダー DB インスタンスでトランザクションを効率的に適用できない場合に発生します。異なるワークロードでは、一時的に、または継続的にレプリカの遅延が発生する可能性があります。一般的な原因の例をいくつか次に示します。

書き込みの同時実行性が高いか、ライター DB インスタンスで大量のバッチ更新が行われるため、リーダー DB インスタンスの適用プロセスが遅れている。
1 つ以上のリーダー DB インスタンスでリソースを使用しており、読み取りワークロード負荷が高い。低速または大規模なクエリを実行すると、適用プロセスに影響し、レプリカの遅延が発生する可能性があります。
大量のデータまたは DDL ステートメントを変更するトランザクション。データベースのコミットの順序を保持する必要があるため、レプリカの遅延が一時的に増加することがあります。

レプリカの遅延の軽減

RDS for MySQL および RDS for PostgreSQL のマルチ AZ DB クラスターでは、ライター DB インスタンスの負荷を軽減することで、レプリカの遅延を軽減できます。また、フロー制御を使用してレプリカの遅延を軽減できます。フロー制御は、ライター DB インスタンスに対する書き込みをスロットリングすることで機能します。これにより、レプリカの遅延が無制限に増加し続けることを防ぎます。書き込みスロットリングは、トランザクションの最後に遅延を追加することで実現されます。これにより、ライター DB インスタンスの書き込みスループットが低下します。フロー制御は遅延をなくすことを保証するものではありませんが、多くのワークロードで全体的な遅延を軽減するのに役立ちます。次のセクションでは、RDS for MySQL および RDS for PostgreSQL でのフロー制御の使用方法について説明します。

RDS for MySQL でのフロー制御によるレプリカの遅延の軽減

RDS for MySQL マルチ AZ DB クラスターを使用している場合、動的パラメータ rpl_semi_sync_master_target_apply_lag を使用することでデフォルトでフロー制御が有効になります。このパラメータは、レプリカの遅延における上限を指定します。レプリカの遅延が設定された上限に近づくと、フロー制御は指定された値より小さいレプリカの遅延を含むようにライター DB インスタンス上の書き込みトランザクションをスロットリングします。場合によっては、レプリカの遅延が指定された上限を超えることがあります。デフォルトでは、パラメータは 120 秒に設定されています。フロー制御を無効にするには、このパラメータを最大値の 86400 秒 (1 日) に設定します。

フロー制御によって挿入される現在の遅延を表示するには、次のクエリを実行してパラメータ Rpl_semi_sync_master_flow_control_current_delay を表示します。


SHOW GLOBAL STATUS like '%flow_control%';

出力は次のようになります。


+-------------------------------------------------+-------+
| Variable_name                                   | Value |
+-------------------------------------------------+-------+
| Rpl_semi_sync_master_flow_control_current_delay | 2010  |
+-------------------------------------------------+-------+
1 row in set (0.00 sec)

注記

遅延はマイクロ秒単位で示されます。

RDS for MySQL マルチ AZ DB クラスターの Performance Insights を有効にすると、クエリがフロー制御によって遅延したことを示す SQL ステートメントに対応する待機イベントをモニタリングできます。フロー制御により遅延が発生すると、Performance Insights ダッシュボードで SQL ステートメントに対応する待機イベント /wait/synch/cond/semisync/semi_sync_flow_control_delay_cond を表示できます。これらのメトリクスを表示するには、Performance Schema が有効になっていることを確認してください。Performance Insights の詳細については、「Amazon RDS での Performance Insights を使用したDB 負荷のモニタリング」を参照してください。

RDS for PostgreSQL でのフロー制御によるレプリカの遅延の軽減

RDS for PostgreSQL のマルチ AZ DB クラスターを使用している場合、フロー制御は拡張機能としてデプロイされています。これにより、DB クラスターのすべての DB インスタンスでバックグラウンドワーカーが開始します。デフォルトでは、リーダー DB インスタンスのバックグラウンドワーカーは、現在のレプリカの遅延をライター DB インスタンスのバックグラウンドワーカーに伝えます。いずれかのリーダー DB インスタンスで遅延が 2 分を超える場合、ライター DB インスタンスのバックグラウンドワーカーは、トランザクションの最後に遅延を追加します。遅延のしきい値を制御するには、パラメータ flow_control.target_standby_apply_lag を使用します。

フロー制御が PostgreSQL プロセスをスロットリングすると、pg_stat_activity および Performance Insights の Extension 待機イベントに表示されます。現在追加されている遅延の量に関する詳細が関数 get_flow_control_stats に表示されます。

フロー制御は、短いが負荷の高い同時トランザクションを持つほとんどのオンライントランザクション処理 (OLTP) のワークロードにメリットがあります。バッチ操作などの長時間実行されるトランザクションによって遅延が発生した場合、それほど大きなメリットはありません。

フロー制御を無効にするには、preload_shared_libraries から拡張機能を削除するか、DB インスタンスを再起動します。

マルチ AZ DB クラスターのフェイルオーバープロセス

マルチ AZ DB クラスター内のライター DB インスタンスで計画的な機能停止または計画外の機能停止が発生した場合、Amazon RDS は別のアベイラビリティーゾーンのリーダー DB インスタンスに自動的にフェイルオーバーします。フェイルオーバーが完了するまでにかかる時間は、データベースアクティビティや、ライターDB インスタンスが使用できなくなった時点の他の条件によって異なります。フェイルオーバーの時間は通常 35 秒未満です。フェイルオーバーは、両方のリーダー DB インスタンスが、失敗したライターからの未処理のトランザクションを適用すると完了します。フェイルオーバーが完了してから、新しいアベイラビリティーゾーンが RDS コンソールに反映されるまでさらに時間がかかる場合があります。

自動フェイルオーバー

Amazon RDS はフェイルオーバーを自動的に処理するため、管理者が操作しなくても可能な限りすみやかにデータベース操作を再開できます。フェイルオーバーするには、ライター DB インスタンスがリーダー DB インスタンスに自動的に切り替わります。

マルチ AZ DB クラスターを手動でフェイルオーバーする

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");					
				
```

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

マルチAZ DB インスタンスのデプロイ

マルチ AZ DB クラスターの作成