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

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

トピック

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

重要

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

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

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

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

マルチ AZ DB クラスターでは、Amazon RDS は DB エンジンのネイティブレプリケーション機能を使用して、ライター DB インスタンスから両方のリーダー DB インスタンスにデータを複製します。ライター DB インスタンスに変更が加えられると、各リーダー 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 を変更、再起動、または削除できます。

マルチ AZ DB クラスターのスナップショットを作成するには「マルチ AZ DB クラスターのスナップショットの作成」の手順に従います。

マルチ AZ DB クラスターを指定の時点に復元するには「マルチ AZ DB クラスターを指定の時点の状態に復元する」の手順に従います。

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

マルチ AZ DB クラスターの接続の管理

マルチ AZ DB クラスターには、単一の DB インスタンスではなく、3 つの DB インスタンスがあります。各接続は特定の DB インスタンスで処理されます。マルチ AZ DB クラスターに接続すると、指定したホスト名とポートがエンドポイントと呼ばれる完全修飾ドメイン名をポイントします。マルチ AZ DB クラスターは、エンドポイントメカニズムを使用してこれらの接続を抽象化します。そのため、一部の DB インスタンスが使用できないときにすべてのホスト名をハードコードしたり、接続のルート再設定を行うために独自のロジックを記述する必要はありません。

ライターエンドポイントは、読み取りと書き込みの両方の操作をサポートする DB クラスターのライター DB インスタンスに接続します。リーダーエンドポイントは、読み取り操作のみをサポートする 2 つのリーダー DB インスタンスのいずれかに接続します。

エンドポイントを使用すると、ユースケースに基づいて各接続を対応する DB インスタンスまたは DB インスタンスグループにマッピングできます。例えば、DDL および DML ステートメントを実行するために、ライター DB インスタンスであるどちらの DB インスタンスにも接続できます。クエリを実行するには、リーダーエンドポイントに接続して、マルチ AZ DB クラスターがリーダー DB インスタンス間の接続を自動的に管理するようにします。診断またはチューニングの場合は、特定の DB インスタンスエンドポイントに接続して、特定の DB インスタンスに関する詳細を調査できます。

DB インスタンスへの接続方法については、「Amazon RDS DB インスタンスへの接続」を参照ください。　　　

トピック

マルチ AZ DB クラスターエンドポイントの種類
マルチ AZ DB クラスターのエンドポイントの表示
クラスターエンドポイントの使用
リーダーエンドポイントの使用
インスタンスエンドポイントの使用
マルチ AZ DB エンドポイントが高可用性でどのように機能するか

マルチ AZ DB クラスターエンドポイントの種類

エンドポイントは、ホストアドレスを含む一意の ID によって表されます。マルチ AZ DB クラスターでは、以下のタイプのエンドポイントを使用できます。

クラスターエンドポイント

マルチ AZ DB クラスターのクラスターエンドポイント (またはライターエンドポイント) は、その DB クラスターの現在のライター DB インスタンスに接続します。このエンドポイントは、DDL や DML ステートメントなどの書き込みオペレーションを実行できる唯一のエンドポイントです。このエンドポイントは、読み取り操作を実行することもできます。

マルチ AZ DB クラスターごとに 1 つのクラスターエンドポイントと 1 つのライター DB インスタンスがあります。

クラスターエンドポイントは、DB クラスターに対するすべての書き込みオペレーション (挿入、更新、削除、DDL の変更など) で使用します。クラスターエンドポイントは、クエリなどの読み取りオペレーションでも使用できます。

DB クラスターの現在のライター DB インスタンスが失敗した場合、マルチ AZ DB クラスターは新しいライター DB インスタンスに自動的にフェイルオーバーします。フェイルオーバー中、DB クラスターは、新しいライター DB インスタンスからクラスターエンドポイントへの接続リクエストに継続して対応し、サービスの中断は最小限に抑えられます。

次の例では、マルチ AZ DB クラスターのクラスターエンドポイントを示します。

mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com

リーダーエンドポイント

マルチAZ DB クラスターのリーダーエンドポイントは、DB クラスターへの読み取り専用接続をサポートしています。リーダーエンドポイントは、SELECT クエリなどの読み取りオペレーションで使用します。このエンドポイントは、リーダー DB インスタンスでこれらのステートメントを処理することにより、ライター DB インスタンスのオーバーヘッドを削減します。また、クラスターが同時SELECTクエリを処理する能力を拡張するのにも役立ちます。マルチAZ DBクラスターごとに 1 つのリーダーエンドポイントがあります。

リーダーエンドポイントは、リーダー DB インスタンスの 1 つに各接続リクエストを送信します。セッションにリーダーエンドポイントを使用する場合、そのセッションのSELECTなどで読み取り専用ステートメントのみを実行できます。

マルチ AZ DB クラスターのリーダーエンドポイントを次の例に示します。リーダーエンドポイントの読み取り専用インテントは、クラスターエンドポイント名内の -ro で示されます。

mydbcluster.cluster-ro-123456789012.us-east-1.rds.amazonaws.com

インスタンスエンドポイント

インスタンスエンドポイントは、マルチ AZ DB クラスター内の特定の DB インスタンスに接続します。DB クラスターの各 DB インスタンスには、独自のインスタンスエンドポイントがあります。したがって、DB クラスター内の現在のライター DB インスタンスに1つのインスタンスエンドポイントがあり、DB クラスター内のリーダー DB ごとに 1 つのインスタンスエンドポイントがあります。

インスタンスエンドポイントは、DB クラスターへの接続の直接制御を提供します。この制御は、クラスターエンドポイントやリーダーエンドポイントの使用が適切でないシナリオに対処するのに役立ちます。例えば、ワークロードタイプに基づき、さらにきめ細かいロードバランシングがアプリケーションに必要になる場合があります。この場合、DB クラスター内の異なるリーダー DB インスタンスに接続して読み取りワークロードを配信するように、複数のクライアントを設定できます。

次の例では、マルチ AZ DB クラスターの DB インスタンスのインスタンスエンドポイントを示します。

mydbinstance.123456789012.us-east-1.rds.amazonaws.com

マルチ AZ DB クラスターのエンドポイントの表示

AWS Management Consoleでは、それぞれのマルチ AZ DB クラスターの詳細ページにクラスターエンドポイントとリーダーエンドポイントが表示されます。インスタンスエンドポイントは、各 DB インスタンスの詳細ページに表示されます。

AWS CLIでは、describe-db-clusters コマンドの出力にライターエンドポイントとリーダーエンドポイントが表示されます。例えば、次のコマンドは、現在の AWS リージョンにあるすべてのクラスターのエンドポイント属性を表示します。


aws rds describe-db-cluster-endpoints

Amazon RDS API では、DescribeDBClusterEndpoints アクションを呼び出してエンドポイントを取得します。出力には Amazon Aurora DB クラスターエンドポイントが存在する場合も表示されます。

クラスターエンドポイントの使用

それぞれのマルチ AZ DB クラスターには単一の組み込みクラスターエンドポイントがあり、その名前とその他の属性は Amazon RDS によって管理されます。ユーザーが、この種のエンドポイントを作成、削除、または変更することはできません。

クラスターエンドポイントは、DB クラスターの管理、抽出/変換/ロード (ETL) オペレーションの実行、およびアプリケーションの開発やテストに使用します。クラスターエンドポイントは、クラスターのライター DB インスタンスに接続します。ライター DB インスタンスは、テーブルとインデックスの作成、ステートメントINSERTの実行、およびその他の DDL および DML 操作を実行できる唯一の DB インスタンスです。

フェールオーバーメカニズムが新しい DB インスタンスをクラスターのライター DB インスタンスに昇格させると、クラスターエンドポイントが指す物理 IP アドレスが変更されます。何らかの形式の接続プールや他の多重化を使用している場合は、キャッシュされた DNS 情報の有効時間をフラッシュまたは削減する必要があります。これにより、フェイルオーバー後に使用不可または読み取り専用になった DB インスタンスに読み取り/書き込み接続を試行できないようにします。

リーダーエンドポイントの使用

マルチ AZ DBクラスターへの読み取り専用接続にはリーダーエンドポイントを使用します。このエンドポイントは、DB クラスターでクエリを大量に消費するワークロードを処理するのに役立ちます。リーダーエンドポイントは、クラスターに対してレポートや他の読み取り専用のオペレーションを実行するアプリケーションに指定します。リーダーエンドポイントは、マルチ AZ DB クラスターで使用可能なリーダーDBインスタンスへの接続を送信します。

それぞれのマルチ AZ クラスターごとに組み込まれている単一のリーダーエンドポイントの名前や他の属性は Amazon RDS で管理されます。ユーザーが、この種のエンドポイントを作成、削除、または変更することはできません。

インスタンスエンドポイントの使用

マルチ AZ DBクラスターの DB インスタンスごとに個別に組み込まれているインスタンスエンドポイントの名前や他の属性は Amazon RDS で管理されます。ユーザーが、この種のエンドポイントを作成、削除、または変更することはできません。マルチ AZ DB クラスターでは、通常、インスタンスエンドポイントよりもライターエンドポイントとリーダーエンドポイントを頻繁に使用します。

日常的なオペレーションでインスタンスエンドポイントを主に使用するのは、マルチ AZ DBクラスター内の特定の DB インスタンスに影響している容量やパフォーマンスの問題を診断する場合です。特定の DB インスタンスに接続しているときに、そのステータス可変、メトリクスなどを調査できます。これを行うと、クラスター内の他の DB インスタンスで起こっていることは異なる、その DB インスタンスで起こっていることを判断するのに役立ちます。

マルチ AZ DB エンドポイントが高可用性でどのように機能するか

高可用性が重要であるマルチ AZ DB クラスターでは、ライターエンドポイントを読み取り/書き込み接続や汎用接続に使用し、リーダーエンドポイントを読み取り専用接続に使用します。ライターエンドポイントとリーダーエンドポイントは、インスタンスエンドポイントよりも DB インスタンスのフェイルオーバーを適切に管理します。インスタンスエンドポイントとは異なり、ライターエンドポイントとリーダーエンドポイントは、クラスター内の DB インスタンスが利用できなくなった場合に、接続先の DB インスタンスを自動的に変更します。

DB クラスターのライター DBインスタンスが失敗した場合、 Amazon RDS は新しいライター DB インスタンスに自動的にフェイルオーバーします。これは、リーダー DB インスタンスを新しいライター DB インスタンスに昇格させることによって行われます。フェイルオーバーが発生した場合、ライターエンドポイントを使用して、新しく昇格させたライター DB インスタンスに再接続できます。または、リーダーエンドポイントを使用して DB クラスター内のリーダー DB インスタンスの 1 つに再接続することもできます。フェールオーバー中に、リーダー DB インスタンスが新しいライター DB インスタンスに昇格された後、リーダーエンドポイントが DB クラスターの新しいライター DB インスタンスへの接続を短時間指示する場合があります。インスタンスエンドポイントへの接続を管理するように独自のアプリケーションロジックを設計する場合は、DB クラスター内の使用可能な DB インスタンスの結果セットを手動またはプログラムで検出できます。

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 デプロイまたはマルチ AZ DB インスタンスデプロイをマルチ AZ DB クラスターデプロイに少ないダウンタイムで移行するには、マルチ AZ DB 蔵sたーリードレプリカを作成します。ソースとして、シングル AZ デプロイの DB インスタンス、またはマルチ AZ DB インスタンスデプロイのプライマリ DB インスタンスを指定します。DB インスタンスは、マルチ AZ DB クラスターへの移行時に書き込みトランザクションを処理できます。

以下は、マルチ AZ DB クラスターのリードレプリカを作成する前の考慮事項です。

ソース DB インスタンスは、マルチ AZ DB クラスターをサポートするバージョンである必要があります。詳細については、「マルチ AZ DB クラスター」を参照してください。
マルチ AZ DB クラスターのリードレプリカは、ソースと同じメジャーバージョンで、同じかそれ以上のマイナーバージョンでなければなりません。
バックアップ保持期間を 0 以外の値に設定することで、ソース DB インスタンスで自動バックアップを有効にする必要があります。
ソース DB インスタンスに割り当てられるストレージは 100 GiB 以上でなければなりません。
アクティブな長時間実行トランザクションの場合、リードレプリカの作成プロセスに時間がかかることがあります。長時間実行トランザクションが完了してから、リードレプリカを作成することをお勧めします。
AWS リージョン内では、ソース DB インスタンスの Amazon VPC に基づく同じ仮想プライベートクラウド (VPC) 内にすべてのリードレプリカを作成することを強くお勧めします。

リードレプリカをソース DB インスタンスとは異なる VPC に作成すると、クラスレスドメイン間ルーティング (CIDR) の範囲がレプリカと RDS システムとの間で重複する可能性があります。CIDR が重複すると、レプリカが不安定になり、レプリカに接続するアプリケーションに悪影響を及ぼす可能性があります。リードレプリカの作成時にエラーが発生した場合は、別のターゲット DB サブネットグループを選択します。詳細については、「VPC 内の DB インスタンスの使用」を参照してください。
マルチ AZ DB クラスターのリードレプリカのソース DB インスタンスを削除した場合、リードレプリカはスタンドアロンのマルチ AZ DB クラスターに昇格されます。

トピック

マルチ AZ DB クラスターのリードレプリカの作成と昇格
マルチ AZ DB クラスターのリードレプリカの作成に関する制限事項

マルチ AZ DB クラスターのリードレプリカの作成と昇格

マルチAZ DB クラスターのリードレプリカの作成と昇格には、AWS Management Console、AWS CLI、または RDS API を使用します。

リードレプリカを使用してシングル AZ デプロイまたはマルチ AZ DB インスタンスデプロイをマルチ AZ DB クラスターに移行するには、AWS Management Console を使用して次の手順を実行します。

AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
マルチ AZ DB クラスターのリードレプリカを作成します。
1. ナビゲーションペインで、[データベース] を選択します。
2. リードレプリカのソースとして使用する DB インスタンスを選択します。
3. [アクション] で [リードレプリカの作成] を選択します。
4. [Availability and durability] (可用性と耐久性) で、[Multi-AZ DB cluster] (マルチ AZ DB クラスター) を選択します。
5. DB インスタンス識別子に、リードレプリカの名前を入力します。
6. 残りのセクションで、DB クラスター設定を指定します。設定の詳細については、「マルチ AZ DB クラスターを作成するための設定」を参照してください。
7. [Create read replica] を選択します。
準備ができたら、リードレプリカをスタンドアロンのマルチ AZ DB クラスターに昇格します。
1. トランザクションがソース DB インスタンスに書き込まれるのを停止して、すべての更新がリードレプリカに反映されるまで待ちます。
  
  データベースの更新は、プライマイ DB インスタンスで行われた後にリードレプリカで行われます。このレプリケーションのラグは大きく異なる可能性があります。ReplicaLag メトリクスを使用して、リードレプリカにすべての更新がいつ加えられたかを確認できます。レプリカラグの詳細については、「リードレプリケーションのモニタリング」を参照してください。
2. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
3. Amazon RDS コンソールで、[Databases (データベース)] を選択します。
  
  [Databases (データベース)] ペインが表示されます。各リードレプリカには､[Role (ロール)] 列に [Replica (レプリカ)] があります｡
4. 昇格するマルチ AZ DBクラスターのリードレプリカを選択します。
5. [アクション] で、[Promote (昇格)] を選択します。
6. [Promote read replica] (リードレプリカの昇格) ページで、新しく昇格されたマルチ AZ DB クラスターのバックアップ保持期間とバックアップウィンドウを入力します。
7. 希望通りの設定になったら、[Promote read replica] (リードレプリカの昇格) を選択します。
8. 昇格されたマルチ AZ DB クラスターのステータスが Available になるまで待ちます。
9. 昇格されたマルチ AZ DB クラスターを使用するようにアプリケーションに指示します。
必要に応じて、シングル AZ デプロイまたはマルチ AZ DB インスタンスデプロイが不要になった場合は削除します。手順については、「DB インスタンスを削除する」を参照してください。

リードレプリカを使用してシングル AZ デプロイまたはマルチ AZ DB インスタンスデプロイをマルチ AZ DB クラスターに移行するには、AWS CLI を使用して次の手順を実行します。

マルチ AZ DB クラスターのリードレプリカを作成します。

ソース DB インスタンスからリードレプリカを作成するには、AWS CLI コマンド create-db-cluster を使用します。--replication-source-identifier として、ソース DB インスタンスの Amazon リソースネーム (ARN) を指定します。

Linux、macOS、Unix の場合:
```
aws rds create-db-cluster \
--db-cluster-identifier mymultiazdbcluster \
--replication-source-identifier arn:aws:rds:us-east-2:123456789012:db:mydbinstance
```
Windows の場合:
```
aws rds create-db-cluster ^
--db-cluster-identifier mymultiazdbcluster ^
--replication-source-identifier arn:aws:rds:us-east-2:123456789012:db:mydbinstance
```
トランザクションがソース DB インスタンスに書き込まれるのを停止して、すべての更新がリードレプリカに反映されるまで待ちます。

データベースの更新は、プライマイ DB インスタンスで行われた後にリードレプリカで行われます。このレプリケーションのラグは大きく異なる可能性があります。Replica Lag メトリクスを使用して、リードレプリカにすべての更新がいつ加えられたかを確認できます。レプリカラグの詳細については、「リードレプリケーションのモニタリング」を参照してください。
準備ができたら、リードレプリカをスタンドアロンのマルチ AZ DB クラスターに昇格します。

マルチ AZ DB クラスターのリードレプリカを昇格するには、AWS CLI コマンド promote-read-replica-db-cluster を使用します。--db-cluster-identifier として、マルチ AZ DB クラスターリードレプリカの ID を指定します。
```
aws rds promote-read-replica-db-cluster --db-cluster-identifier mymultiazdbcluster
```
昇格されたマルチ AZ DB クラスターのステータスが Available になるまで待ちます。
昇格されたマルチ AZ DB クラスターを使用するようにアプリケーションに指示します。

必要に応じて、シングル AZ デプロイまたはマルチ AZ DB インスタンスデプロイが不要になった場合は削除します。手順については、「DB インスタンスを削除する」を参照してください。

リードレプリカを使用してシングル AZ デプロイまたはマルチ AZ DB インスタンスデプロイをマルチ AZ DB クラスターに移行するには、RDS AAPI を使用して次の手順を実行します。

マルチ AZ DB クラスターのリードレプリカを作成します。

マルチ AZ DB クラスターのリードレプリカを作成するには、必須パラメータ DBClusterIdentifier を指定して、CreateDBCluster オペレーションを使用します。ReplicationSourceIdentifier として、ソース DB インスタンスの Amazon リソースネーム (ARN) を指定します。
トランザクションがソース DB インスタンスに書き込まれるのを停止して、すべての更新がリードレプリカに反映されるまで待ちます。

データベースの更新は、プライマイ DB インスタンスで行われた後にリードレプリカで行われます。このレプリケーションのラグは大きく異なる可能性があります。Replica Lag メトリクスを使用して、リードレプリカにすべての更新がいつ加えられたかを確認できます。レプリカラグの詳細については、「リードレプリケーションのモニタリング」を参照してください。
準備ができたら、リードレプリカをスタンドアロンのマルチ AZ DB クラスターに昇格します。

マルチ AZ DB クラスターのリードレプリカを昇格するには、必須パラメータ DBClusterIdentifier を指定して、PromoteReadReplicaDBCluster オペレーションを使用します。マルチ AZ DB クラスターリードレプリカの ID を指定します。
昇格されたマルチ AZ DB クラスターのステータスが Available になるまで待ちます。
昇格されたマルチ AZ DB クラスターを使用するようにアプリケーションに指示します。

マルチ AZ DB クラスターのリードレプリカの作成に関する制限事項

次の制限は、シングル AZ デプロイまたはマルチ AZ DB インスタンスデプロイからマルチ AZ DB クラスターのリードレプリカを作成する際に適用されます。

マルチ AZ DB クラスターのリードレプリカは、RDS for PostgreSQL DB インスタンスをソースとしてのみ作成できます。マルチ AZ DB クラスターのリードレプリカは、RDS for MySQL DB インスタンスをソースとして作成することはできません。
ソース DB インスタンスを所有する AWS アカウントとは異なる AWS アカウントでは、マルチ AZ DBAWS クラスターのリードレプリカを作成することはできません。
マルチ AZ DB クラスターのリードレプリカは、ソース DB インスタンスとは異なる AWS リージョンで作成することはできません。
マルチ AZ DB クラスターのリードレプリカを指定の時点に復元することはできません。
ストレージ暗号化は、ソース DB インスタンスとマルチ AZ DB クラスターで同じ設定にする必要があります。
ソース DB インスタンスが暗号化されている場合、マルチ AZ DB クラスターのリードレプリカは同じ KMS キーを使用して暗号化する必要があります。
ソース DB インスタンスでマイナーバージョンアップグレードを実行するには、まず、マルチ AZ DB クラスターリードレプリカでマイナーバージョンアップグレードを実行する必要があります。
マルチ AZ DB クラスターでメジャーバージョンアップグレードを実行することはできません。
マルチ AZ DB クラスターリードレプリカのソース DB インスタンスでメジャーバージョンアップグレードを実行できますが、リードレプリカへのレプリケーションは停止し、再開できません。
マルチ AZ DB クラスターのリードレプリカは、カスケードリードレプリカをサポートしていません。
RDS for PostgreSQL では、マルチ AZ DB クラスターのリードレプリカはフェイルオーバーできません。

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

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

トピック

自動フェイルオーバー
マルチ AZ DB クラスターを手動でフェイルオーバーする
マルチ AZ DB クラスターがフェイルオーバーしたかどうかの判別
DNS 名参照用の JVM TTL の設定

自動フェイルオーバー

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

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

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

マルチ AZ DB クラスターは、プロビジョンド IOPS ストレージのみをサポートします。
シングル AZ DB インスタンスデプロイまたはマルチ AZ DB インスタンスデプロイをマルチ AZ DB クラスターに変更することはできません。代わりに、シングル AZ DB インスタンスデプロイまたはマルチ AZ DB インスタンスデプロイのスナップショットをマルチ AZ DB クラスターに復元することができます。
マルチ AZ DB クラスターは DB インスタンスレベルでの変更をサポートしていません。これは、すべての変更は DB クラスターレベルで行われるためです。
マルチ AZ DB クラスターでは、次の機能はサポートされていません。
- Amazon RDS Proxy
- IPv6 接続のSupport（デュアルスタックモード）
- マルチ AZ DB クラスタースナップショットデータを Amazon S3 バケットにエクスポートする
- IAM DB authentication
- Kerberos 認証
- ポートの変更
  
  別の方法として、マルチ AZ DB クラスターを特定の時点に復元し、別のポートを指定することもできます。
- オプショングループ
- マルチ AZ DB クラスターソースによるリードレプリカの作成
- リザーブド 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
RDS for MySQL マルチ AZ DB クラスターでは、その他のストアドプロシージャはサポートされていません。これらの手順については、「Amazon RDS MySQL の SQL リファレンス」を参照してください。
RDS for PostgreSQL マルチ AZ DB クラスターは、次の PostgreSQL エクステンションをサポートしていません。aws_s3、pg_transport、およびpglogical。
RDS for PostgreSQL マルチ AZ DB クラスターは、アウトバウンドネットワークアクセスでのカスタム DNS サーバーの使用をサポートしていません。
RDS for PostgreSQL マルチ AZ DB クラスターは、論理的な複製をサポートしていません。

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

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

ドキュメントの表記規則

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

Amazon RDS での DB インスタンスの請求