DB インスタンスのリードレプリカの操作 - Amazon Relational Database Service

DB インスタンスのリードレプリカの操作

リードレプリカは、DB インスタンスの読み取り専用コピーです。クエリをアプリケーションからリードレプリカにルーティングすることにより、プライマリ DB インスタンスの負荷を軽減できます。こうすることにより、単一 DB インスタンスの容量制約にとらわれることなく伸縮自在にスケールアウトし、読み取り負荷の高いデータベースワークロードに対応できます。

ソース DB インスタンスからリードレプリカを作成するには、Amazon RDS では、DB エンジン組み込みのレプリケーション機能を使用します。特定のエンジンでのリードレプリカの使用については、以下のセクションを参照してください。

ソース DB インスタンスからリードレプリカを作成すると、ソースがプライマリ DB インスタンスになります。プライマリ DB インスタンスに対して更新を行うと、Amazon RDS はリードレプリカに非同期的にコピーします。次の図は、ソース DB インスタンスが別のアベイラビリティーゾーン (AZ) のリードレプリカにレプリケートされる様子を示しています。クライアントにはプライマリ DB インスタンスへの読み取り/書き込みアクセス権、およびレプリカへの読み取り専用アクセス権があります。


            リードレプリカの設定

Amazon RDS リードレプリカの概要

次のセクションでは、DB インスタンスのリードレプリカについて説明します。マルチ AZ DB クラスターのリードレプリカについては、「マルチ AZ DB クラスターのリードレプリカの操作」を参照してください。

リードレプリカのユースケース

以下のような状況では、ソース DB インスタンスに対する 1 つまたは複数のリードレプリカのデプロイが適している可能性があります。

  • 読み込みが多いデータベースに対して 1 つの DB インスタンスの処理または I/O 機能を拡張します。このような過度の読み込みトラフィックを 1 つまたは複数のリードレプリカに割り振ることができます。

  • ソース DB インスタンスが利用可能でない場合に読み込みトラフィックを誘導します。場合によっては、バックアップまたは予定される保守による I/O 停止により、ソース DB インスタンスで I/O リクエストを取得できないことがあります。このような場合は、リードトラフィックをリードレプリカに誘導することができます。このようなユースケースの場合、ソース DB インスタンスを利用できないため、リードレプリカのデータは「古い」場合があるので注意が必要です。

  • ビジネスレポーティングまたはデータウェアハウジングでは、本稼働 DB インスタンスではなく、ビジネスレポーティングクエリをリードレプリカに対して実行します。

  • 災害復旧の実装。プライマリ DB インスタンスで障害が発生した場合、災害対策ソリューションとして、リードレプリカをスタンドアロンインスタンスに昇格させることができます。

リードレプリカの仕組み

リードレプリカを作成したら、最初に既存の DB インスタンスをソースとして指定します。次に、Amazon RDS でソースインスタンスのスナップショットを作成し、スナップショットから読み取り専用インスタンスを作成します。Amazon RDS では、DB エンジン用の非同期レプリケーションの方法を使用することで、プライマリ DB インスタンスに変更がある場合は必ずリードレプリカが更新されます。

リードレプリカは、読み取り専用接続のみ許可される DB インスタンスとして動作します。例外は、RDS for Oracle DB エンジンで、これはマウントモードでレプリカデータベースをサポートします。マウントされたレプリカはユーザー接続を受け付けないため、読み取り専用のワークロードに対応できません。マウントされたレプリカの主な用途は、クロスリージョンの災害対策です。詳細については、「Amazon RDS for Oracle でのリードレプリカの使用」を参照してください。

アプリケーションは、DB インスタンスの場合と同じ方法でリードレプリカに接続します。Amazon RDS では、ソース DB インスタンスからのすべてのデータベースがレプリケートされます。

マルチ AZ 配置のリードレプリカ

マルチ AZ 配置で高可用性を持つように設定されたスタンバイレプリカもある DB インスタンスのリードレプリカを設定できます。スタンバイレプリカとのレプリケーションは同期的です。リードレプリカとは異なり、スタンバイレプリカは読み取りトラフィックを処理できません。

次のシナリオでは、クライアントは 1 つの AZ のプライマリ DB インスタンスへの読み取り/書き込みアクセス権を持っています。プライマリインスタンスは、更新を 2 番目の AZ のリードレプリカに非同期でコピーし、さらに 3 番目の AZ のスタンバイレプリカにも同期的にコピーします。クライアントはリードレプリカに対してのみ読み取りアクセス権を持ちます。


                    リードレプリカとスタンバイレプリカの設定

高可用性レプリカとスタンバイレプリカの詳細については、「マルチ AZ 配置の設定と管理」を参照してください。

クロスリージョンリードレプリカ

リードレプリカは、そのプライマリ DB インスタンスとは異なる AWS リージョン に存在する場合があります。このような場合、Amazon RDS によりプライマリ DB インスタンスとリードレプリカ間の安全な通信チャネルが設定されます。Amazon RDS では、セキュリティグループエントリの追加など、安全なチャネルを有効にするために必要な AWS のセキュリティ設定を確立できます。クロスリージョンリードレプリカの詳細については、「別の AWS リージョン でのリードレプリカの作成」を参照してください。

この章の情報は、ソースの DB インスタンスと同じ AWS リージョン または別の AWS リージョン における Amazon RDS リードレプリカの作成に適用されます。以下の情報は、Amazon EC2 インスタンスまたはオンプレミスで実行されているインスタンスでレプリケーションをセットアップする場合には適用されません。

DB エンジンのリードレプリカ間の違い

Amazon RDS DB エンジンによるレプリケーションの実装方法は異なるため、知っておくべき大きな違いがいくつかあります。詳細を以下のテーブルに示します。

機能または動作 MySQL と MariaDB Oracle PostgreSQL SQL Server

レプリケーション方法

論理レプリケーション。

物理レプリケーション。

物理レプリケーション。

物理レプリケーション。

トランザクションログの消去方法

RDS for MySQL および RDS for MariaDB では、適用されていないバイナリログは維持されます。

プライマリ DB インスタンスにクロスリージョンのリードレプリカがない場合、Amazon RDS for Oracle は、ソース DB インスタンスで最低 2 時間のトランザクションログを保持します。2 時間後、またはアーカイブログの保持時間設定のいずれか長い方の時間が経過すると、ログはソース DB インスタンスから削除されます。ログがデータベースに正常に適用された場合にのみ、アーカイブログの保持時間設定が経過すると、ログはリードレプリカから削除されます。

プライマリ DB インスタンスには、1 つ以上のクロスリージョンのリードレプリカが存在する場合があります。その場合 Amazon RDS for Oracle は、ソース DB インスタンスのトランザクションログが転送され、すべてのクロスリージョンリードレプリカに適用されるまで保持します。

アーカイブログの保持時間の設定については、「アーカイブ REDO ログの保持」を参照してください。

PostgreSQL にはパラメータ wal_keep_segments があり、これによって、データをリードレプリカに提供するために保持する先書きログ (WAL) ファイルの数が決まります。パラメータ値は、保持するログの数を指定します。

プライマリレプリカのトランザクションログファイルの仮想ログファイル (VLF) は、セカンダリレプリカで不要になったら切り捨てることができます。

VLF は、レプリカでログレコードがハードニングされている場合にのみ非アクティブとしてマークできます。プライマリレプリカ内でのディスクサブシステムの速度に関係なく、トランザクションログは、最も遅いレプリカで強化されるまで VLF を保持します。

レプリカを書き込み可能にできるか

はい。MySQL または MariaDB リードレプリカは書き込み可能にすることができます。

いいえ。Oracle リードレプリカは物理的なコピーであり、Oracle ではリードレプリカでの書き込みは許可されていません。リードレプリカを昇格させて書き込み可能にすることができます。昇格したリードレプリカには、昇格をリクエストされた時点までのレプリケートされたデータがあります。

いいえ。PostgreSQL リードレプリカは物理的なコピーであり、PostgreSQL ではリードレプリカを書き込み可能にすることはできません。

いいえ。SQL Server リードレプリカは物理コピーであり、同様に書き込み可能にすることはできません。リードレプリカを昇格させて書き込み可能にすることができます。昇格したリードレプリカには、昇格をリクエストされた時点までのレプリケートされたデータがあります。

レプリカでバックアップを実行できるか

はい。自動バックアップと手動スナップショットは、RDS for MySQL または RDS for MariaDB のリードレプリカでサポートされています。

はい。RDS for Oracle リードレプリカでは、自動バックアップと手動スナップショットがサポートされています。

はい、RDS for PostgreSQL リードレプリカの手動スナップショットは作成できます。リードレプリカの自動バックアップは、RDS for PostgreSQL 14.1 以降のバージョンでのみサポートされます。RDS for PostgreSQL 14.1 より前のバージョンの PostgreSQL リードレプリカでは、自動バックアップをオンにすることはできません。RDS for PostgreSQL 13 以前のバージョンでバックアップが必要な場合は、リードレプリカのスナップショットを作成します。

いいえ。 RDS for SQL Server のリードレプリカでは、自動バックアップと手動スナップショットはサポートされていません。

並列レプリケーションを使用できるか

はい。すべてのサポートされている MariaDB および MySQL のバージョンで、並行レプリケーションのスレッドが可能です。

はい。REDO ログデータは、常にプライマリデータベースからそのすべてのリードレプリカに並行して転送されます。

いいえ。PostgreSQL は単一プロセスでレプリケーションを処理します。

はい。REDO ログデータは、常にプライマリデータベースからそのすべてのリードレプリカに並行して転送されます。

レプリカは、読み取り専用ではなくマウント状態で維持できるか

いいえ。

はい。マウントされたレプリカの主な用途は、クロスリージョンの災害対策です。マウントされたレプリカには、Active Data Guard ライセンスは必要ありません。詳細については、「Amazon RDS for Oracle でのリードレプリカの使用」を参照してください。

いいえ。

いいえ。

リードレプリカのストレージタイプ

デフォルトでは、ソース DB インスタンスと同じストレージタイプのリードレプリカが作成されます。ただし、次の表に示すオプションに基づいて、ソース DB インスタンスと別のストレージタイプを持つリードレプリカを作成することもできます。

ソース DB インスタンスストレージのタイプ ソース DB インスタンスストレージの割り当て リードレプリカのストレージタイプのオプション
プロビジョンド IOPS 100 GiB - 64 TiB プロビジョンド IOPS、汎用、マグネティック
汎用 100 GiB - 64 TiB プロビジョンド IOPS、汎用、マグネティック
汎用 100 GiB 未満 汎用、マグネティック
マグネティック 100 GiB~6 TiB プロビジョンド IOPS、汎用、マグネティック
マグネティック 100 GiB 未満 汎用、マグネティック
注記

リードレプリカの割り当て済みストレージを増やす場合は、少なくとも 10% にする必要があります。10 パーセントに満たない単位で増やそうとすると、エラーになります。

レプリカからレプリカを作成する場合の制限事項

Amazon RDS では、循環レプリケーションはサポートされません。既存の DB インスタンスのレプリケーションソースとして機能するように DB インスタンスを設定することはできません。新しいリードレプリカは、既存の DB インスタンスからのみ作成することができます。例えば、MySourceDBInstanceReadReplica1 にレプリケートされる場合、ReadReplica1 に再度レプリケートされるように MySourceDBInstance を設定することはできません。

MariaDB および RDS for MySQL、そして RDS for PostgreSQL の特定のバージョンでは、既存のリードレプリカからリードレプリカを作成することができます。例えば、既存のレプリカ ReadReplica1 から新しいリードレプリカ ReadReplica2 を作成できます。RDS for Oracle および RDS for SQL Server では、既存のリードレプリカからリードレプリカを作成することはできません。

レプリカを削除する際の注意事項

リードレプリカが不要になった場合は、DB インスタンスを削除するのと同じメカニズムを使用して、リードレプリカを明示的に削除できます。同じ AWS リージョン のリードレプリカを削除せずにソース DB インスタンスを削除すると、各リードレプリカはスタンドアロン DB インスタンスに昇格されます。DB インスタンスの削除については、「DB インスタンスを削除する」を参照してください。リードレプリカの昇格の詳細については、「リードレプリカをスタンドアロン DB インスタンスに昇格させる」を参照してください。

クロスリージョンリードレプリカがある場合、そのソース DB インスタンスの削除について、「クロスリージョンレプリケーションに関する考慮事項」を参照してください。

リードレプリカの作成

AWS Management Console、AWS CLI、または RDS API を使用して、既存の DB インスタンスからリードレプリカを作成できます。リードレプリカは、レプリケーション元のソース DB インスタンスの DB インスタンス識別子である SourceDBInstanceIdentifier を指定することで作成できます。

リードレプリカを作成すると、Amazon RDS はソース DB インスタンスの DB スナップショットを取得し、レプリケーションを開始します。その結果、DB スナップショットを作成する間、ソース DB インスタンスに短期間の I/O 停止が発生します。

注記

I/O 停止は通常、約 1 分間続きます。ソース DB インスタンスがマルチ AZ 配置の場合は、I/O 停止を回避できます。スナップショットがセカンダリ DB インスタンスから取得されるためです。

アクティブな長時間実行トランザクションの場合、リードレプリカの作成プロセスに時間がかかることがあります。長時間実行トランザクションが完了してから、リードレプリカを作成することをお勧めします。同じソース DB インスタンスから複数のリードレプリカを同時に作成する場合、Amazon RDS は初回の作成アクションの開始時にスナップショットを 1 つだけ取得します。

リードレプリカを作成するときは、いくつかの考慮事項があります。最初に、バックアップ保持期間を 0 以外の値に設定することで、ソース DB インスタンスで自動バックアップを有効にする必要があります。この要件は、別のリードレプリカのソース DB インスタンスであるリードレプリカにも適用されます。RDS for MySQL のリードレプリカで自動バックアップを有効にするには、まずリードレプリカを作成し、次にそのリードレプリカを変更して自動バックアップを有効にします。

注記

AWS リージョン 内では、Amazon VPC に基づくすべてのリードレプリカをソース DB インスタンスと同じ仮想プライベートクラウド (VPC) に作成することを強くお勧めします。リードレプリカをソース DB インスタンスとは異なる VPC に作成すると、クラスレスドメイン間ルーティング (CIDR) の範囲がレプリカと RDS システムとの間で重複する可能性があります。CIDR が重複すると、レプリカが不安定になり、レプリカに接続するアプリケーションに悪影響を及ぼす可能性があります。リードレプリカの作成時にエラーが発生した場合は、別のターゲット DB サブネットグループを選択します。詳細については、「VPC 内の DB インスタンスの使用」を参照してください。

コンソールまたは AWS CLI を使用して別の AWS アカウント でリードレプリカを直接作成する方法はありません。

ソース DB インスタンスからリードレプリカを作成するには
  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[データベース] を選択します。

  3. リードレプリカのソースとして使用する DB インスタンスを選択します。

  4. [アクション] で [リードレプリカの作成] を選択します。

  5. [DB インスタンス識別子] に、リードレプリカの名前を入力します。

  6. インスタンス設定を選択します。リードレプリカでもソース DB インスタンスと同等以上の DB インスタンスクラスとストレージタイプを使用することをお勧めします。

  7. AWS リージョン では、リードレプリカの作成先のリージョンを指定します。

  8. [ストレージ] では、割り当てられたストレージのサイズや、ストレージの自動スケーリングを使用するかどうかを指定します。

    ソース DB インスタンスが最新のストレージ設定になっていない場合は、[ストレージファイルシステム設定のアップグレード] オプションを使用できます。この設定を有効にすると、リードレプリカのファイルシステムが適切な設定にアップグレードされます。詳細については、「DB インスタンスのストレージファイルシステムのアップグレード」を参照してください。

  9. [可用性] では、レプリカのフェイルオーバーをサポートするために別のアベイラビリティーゾーンにレプリカのスタンバイを作成するかどうかを選択します。

    注記

    リードレプリカは、ソースのデータベースがマルチ AZ DB インスタンスであるかどうかに関係なく、マルチ AZ DB インスタンスとして作成できます。

  10. 他の DB インスタンスの設定を指定します。各可用性設定の詳細については、「DB インスタンスの設定」を参照してください。

  11. 暗号化されたリードレプリカを作成するには、[その他の設定] を展開してから、次の設定を指定します。

    1. [暗号化の有効化] を選択します。

    2. [AWS KMS key] では、KMS キーの AWS KMS key 識別子を選択します。

    注記

    ソース DB インスタンスは暗号化する必要があります。DB インスタンスの暗号化については、「Amazon RDS リソースの暗号化」を参照してください。

  12. [Create read replica] を選択します。

リードレプリカが作成されると、RDS コンソールの [Databases] (データベース) ページに表示されます。[Role] (ロール) 列に [Replica] (レプリカ) が表示されます。

ソース DB インスタンスからリードレプリカを作成するには、AWS CLI コマンド create-db-instance-read-replica を使用します。この例では、割り当てられたストレージサイズを設定し、ストレージの自動スケーリングを有効にします。また、ファイルシステムを適切な設定にアップグレードします。

他の設定を指定できます。各設定の詳細については、「DB インスタンスの設定」を参照してください。

Linux、macOS、Unix の場合:

aws rds create-db-instance-read-replica \ --db-instance-identifier myreadreplica \ --source-db-instance-identifier mydbinstance \ --allocated-storage 100 \ --max-allocated-storage 1000 \ --upgrade-storage-config

Windows の場合:

aws rds create-db-instance-read-replica ^ --db-instance-identifier myreadreplica ^ --source-db-instance-identifier mydbinstance ^ --allocated-storage 100 ^ --max-allocated-storage 1000 ^ --upgrade-storage-config

ソース MySQL、MariaDB、Oracle、PostgreSQL、または SQL Server DB インスタンスから読み取りレプリカを作成するには、次の必須パラメータを指定して Amazon RDS API CreateDBInstanceReadReplica オペレーションを呼び出します。

  • DBInstanceIdentifier

  • SourceDBInstanceIdentifier

リードレプリカをスタンドアロン DB インスタンスに昇格させる

リードレプリカをスタンドアロン DB インスタンスに昇格させることができます。ソース DB インスタンスに複数のリードレプリカがある場合、いずれかのリードレプリカを DB インスタンスに昇格させても、他のレプリカには影響が及びません。

リードレプリカを昇格させると、RDS によって DB インスタンスが使用可能になる前に DB インスタンスが再起動されます。リードレプリカのサイズによっては、昇格プロセスが完了するまで数分以上かかる場合があります。


            リードレプリカの昇格

リードレプリカを昇格させるユースケース

リードレプリカをスタンドアロン DB インスタンスに昇格させる理由には、次のようなものがあります。

  • 障害復旧の実装 – プライマリ DB インスタンスに障害が発生した場合、データ復旧スキームとして、リードレプリカを昇格させることができます。このアプローチは、同期的なレプリケーション、自動障害検出、フェイルオーバーを補完します。

    非同期レプリケーションの影響と制限を承知の上で、データ復旧にリードレプリカの昇格が必要と判断した場合に限り、昇格を行ってください。これを行うには、最初にリードレプリカを作成し、次にプライマリ DB インスタンスで障害をモニタリングします。障害が発生した場合、以下の作業を行います。

    1. リードレプリカを昇格させます。

    2. 昇格された DB インスタンスにデータベーストラフィックを向けます。

    3. 昇格された DB インスタンスとの置き換えリードレプリカをソースとして作成します。

  • ストレージ設定のアップグレード — ソース DB インスタンスが推奨ストレージ設定になっていない場合は、インスタンスのリードレプリカを作成し、ストレージファイルシステム設定をアップグレードできます。このオプションは、リードレプリカのファイルシステムを適切な設定に移行させます。次に、リードレプリカをスタンドアロンインスタンスに昇格させることができます。

    このオプションを使用すると、古い 32 ビットファイルシステムのストレージとファイルサイズのスケーリング制限を克服できます。詳細については、「DB インスタンスのストレージファイルシステムのアップグレード」を参照してください。

    このオプションは、ソース DB インスタンスが最新のストレージ設定になっていない場合、または同じリクエスト内で DB インスタンスクラスを変更する場合にのみ使用できます。

  • シャーディング – シャーディングでは、「share-nothing」アーキテクチャを採用しており、基本的に大きいデータベースが複数の小さいデータベースに分割されます。データベースを分割する一般的な方法としては、同じクエリに結合されていないテーブルを切り離して別のホスト上に配置します。別の方法としては、複数のホスト間でテーブルを複製し、ハッシュアルゴリズムを使用してどのホストで特定の更新を受け取るかを指定します。各シャード (小さいデータベース) に対応するリードレプリカを作成し、スタンドアロンシャードに変換することを決定したら昇格させることができます。次に、要件に応じて、各シャードのテーブルのキースペース (行を分割する場合) または分布を分割できます。

  • DDL 操作の実行 (MySQL および MariaDB のみ) – インデックスの作成や再構築などの DDL 操作には時間がかかることがあり、DB インスタンスのパフォーマンスが大幅に低下する可能性があります。これらのオペレーションは、MySQL リードレプリカや MariaDB リードレプリカがプライマリ DB インスタンスと同期されたら、これらのリードレプリカに対して実行できます。次に、リードレプリカを昇格させ、昇格されたインスタンスを使用するようにアプリケーションに指示できます。

注記

リードレプリカが RDS for Oracle DB インスタンスの場合は、昇格の代わりにスイッチオーバーを実行できます。スイッチオーバーでは、ソース DB インスタンスが新しいレプリカになり、レプリカが新しいソース DB インスタンスになります。詳細については、「Oracle Data ata Guard のスイッチオーバー操作の実行」を参照してください。

昇格されたリードレプリカの特徴

リードレプリカを昇格させると、リードレプリカとして機能しなくなり、スタンドアロン DB インスタンスになります。新しいスタンドアロン DB インスタンスには、次の特徴があります。

  • スタンドアロン DB インスタンスは、昇格前のリードレプリカのオプショングループとパラメータグループを保持します。

  • 新しい DB インスタンスからリードレプリカを作成して、ポイントインタイム復元オペレーションを実行できます。

  • 昇格した DB インスタンスはリードレプリカではなくなったため、レプリケーションターゲットとしては使用できません。

リードレプリカを昇格させるための前提条件

リードレプリカを昇格する前に、次のことを実行してください。

  • バックアップ戦略を確認します。

    • バックアップを有効にし、少なくとも 1 つのバックアップを完了することをお勧めします。バックアップ期間は、以前のバックアップ以降のデータベースに対する変更数の関数です。

    • リードレプリカでバックアップを有効にしている場合は、自動バックアップウィンドウを構成して、毎日のバックアップがリードレプリカの昇格を妨げないようにします。

    • リードレプリカが backing-up ステータスになっていないことを確認します。この状態にあるリードレプリカを昇格させることはできません。

  • プライマリ DB インスタンスに対するトランザクションの書き込みを停止し、すべての更新がリードレプリカに反映されるまで待ちます。

    データベースの更新は、プライマイ DB インスタンスで行われた後にリードレプリカで行われます。レプリケーションのラグは大きく異なる可能性があります。Replica Lag メトリクスを使用して、リードレプリカにすべての更新がいつ加えられたかを確認できます。

  • (MySQL および MariaDB のみ) MySQL または MariaDB のリードレプリカに変更を加えるには、リードレプリカの DB パラメータグループで read_only パラメータを 0 に設定する必要があります。次に、インデックスの作成など、必要なすべての DDL 操作をリードレプリカで実行します。リードレプリカに対するアクションの実行は、プライマリ DB インスタンスのパフォーマンスには影響しません。

リードレプリカの昇格: 基本的な手順

以下のステップは、DB インスタンスにリードレプリカを昇格させる一般的なプロセスを示しています。

  1. Amazon RDS コンソールの [Promote] (昇格) オプション、AWS CLI コマンドの promote-read-replica、または Amazon RDS API の PromoteReadReplica オペレーションを使用して、リードレプリカをプロモートします。

    注記

    昇格プロセスの完了までには数分かかります。リードレプリカを昇格させると、レプリケーションが停止され、リードレプリカが再起動されます。再起動が完了すると、リードレプリカは新しい DB インスタンスとして使用可能になります。

  2. (オプション) 新しい DB インスタンスをマルチ AZ 配置に変更します。詳細については、Amazon RDS DB インスタンスを変更するおよびマルチ AZ 配置の設定と管理を参照してください。

リードレプリカをスタンドアロン DB インスタンスに昇格させるには
  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. Amazon RDS コンソールで、[Databases (データベース)] を選択します。

    [Databases (データベース)] ペインが表示されます。各リードレプリカには、[Role (ロール)] 列に [Replica (レプリカ)] があります。

  3. 昇格させるリードレプリカを選択します。

  4. [アクション] で、[Promote (昇格)] を選択します。

  5. [リードレプリカの昇格] ページで、新しく昇格された DB インスタンスのバックアップ保持期間とバックアップウィンドウを入力します。

  6. すべての設定が正しいことを確認したら、[Continue] を選択します。

  7. 確認ページで、[Promote Read Replica] を選択します。

リードレプリカをスタンドアロン DB インスタンスに昇格させるには、AWS CLI promote-read-replica コマンドを使用します。

Linux、macOS、Unix の場合:

aws rds promote-read-replica \ --db-instance-identifier myreadreplica

Windows の場合:

aws rds promote-read-replica ^ --db-instance-identifier myreadreplica

リードレプリカをスタンドアロン DB インスタンスに昇格するには、必須のパラメータ DBInstanceIdentifier を指定して Amazon RDS API の PromoteReadReplica オペレーションを呼び出します。

リードレプリケーションのモニタリング

リードレプリカのステータスは、さまざまな方法でモニタリングできます。Amazon RDS コンソールは、リードレプリカの詳細にある [Connectivity & security] (接続性とセキュリティ) タブの [Replication] (レプリケーション) セクションでリードレプリカのステータスを表示します。リードレプリカの詳細を表示するには、Amazon RDS コンソールの DB インスタンスのリストでリードレプリカの名前を選択します。


            リードレプリカのステータス

AWS CLI describe-db-instances コマンドまたは Amazon RDS API DescribeDBInstances オペレーションを使用して、リードレプリカのステータスを確認することもできます。

リードレプリカのステータスは、以下のいずれかです。

  • replicating – リードレプリカが正常にレプリケーションされています。

  • replication degraded (SQL Server および PostgreSQL のみ) – レプリカはプライマリインスタンスからデータを受信していますが、1 つ以上のデータベースが更新を取得していない可能性があります。これは、レプリカが新しく作成されたデータベースをセットアップしているときなどに発生します。また、ブルー/グリーンデプロイのブルー環境で、サポートされていない DDL やラージオブジェクトの変更が行われた場合にも発生する可能性があります。

    パフォーマンスが低下した状態でエラーが発生しない限り、ステータスは replication degraded から error に移行しません。

  • error – レプリケーションでエラーが発生しました。Amazon RDS コンソールの [Replication Error] またはイベントをログを確認して、正確なエラーについて調べます。レプリケーションエラーのトラブルシューティングの詳細については、「MySQL リードレプリカに関する問題のトラブルシューティング」を参照してください。

  • terminated (MariaDB、MySQL、または PostgreSQL のみ) – レプリケーションが終了しました。これは、手動またはレプリケーションエラーによってレプリケーションが連続する 30 日超停止した場合に発生します。この場合、Amazon RDS はプライマリ DB インスタンスとすべてのリードレプリカ間のレプリケーションを終了します。Amazon RDS は、ソース DB インスタンスでのストレージ要件の増加と長いフェイルオーバー時間を防ぐためにこれを行います。

    レプリケーションが中断すると、ログに書き込まれるエラーメッセージの量が増えてログのサイズと数が増加するため、ストレージに影響が及ぶ可能性があります。さらに、レプリケーションが中断すると、Amazon RDS が復旧中に大量のログを保持して処理するのに必要な時間が原因で、災害対策にも影響が及ぶ可能性があります。

  • 終了 (Oracle のみ) – レプリケーションは終了します。これは、リードレプリカに十分なストレージが残っていないため、レプリケーションが 8 時間以上停止した場合に発生します。この場合、Amazon RDS はプライマリ DB インスタンスと影響を受けたリードレプリカ間のレプリケーションを終了します。このステータスは終了状態であり、リードレプリカを再作成する必要があります。

  • stopped (MariaDB または MySQL のみ) – お客様がリクエストを開始したため、レプリケーションが停止しました。

  • replication stop point set (MySQL のみ) – お客様が開始した停止ポイントが mysql.rds_start_replication_until ストアドプロシージャを使用して設定され、レプリケーションが進行中です。

  • replication stop point reached (MySQL のみ) – お客様が開始した停止ポイントが mysql.rds_start_replication_until ストアドプロシージャを使用して設定され、レプリケーションは停止ポイントに到達したために停止しました。

DB インスタンスのレプリケート先の場所を確認でき、その場合は、そのレプリケーションステータスを確認できます。RDS コンソールの [Databases] (データベース) ページの [Role] (ロール) 列に [Primary] (プライマリ) と表示されます。その DB インスタンス名を選択します。詳細ページの [Connectivity & security] (接続とセキュリティ) タブの [Replication] (レプリケーション) の下に、レプリケーションの状態が表示されます。

レプリケーションラグのモニタリング

Amazon CloudWatch のレプリケーションのラグをモニタリングするには、Amazon RDS ReplicaLag メトリクスを表示します。

MariaDB と MySQL の場合、ReplicaLag メトリクスでは、Seconds_Behind_Master コマンドの SHOW REPLICA STATUS フィールドの値がレポートされます。MySQL と MariaDB のレプリケーション遅延の一般的な原因は以下のとおりです。

  • ネットワークが停止している。

  • リードレプリカで、インデックスがあるテーブルに書き込んでいる。read_only パラメータがリードレプリカで 0 に設定されていない場合、レプリケーションが中断されることがあります。

  • MyISAM などの非トランザクションストレージエンジンを使用している。レプリケーションは、MariaDB の MySQL および InnoDB ストレージエンジンの XtraDB ストレージエンジンでのみサポートされます。

注記

MariaDB および MySQL の旧バージョンは、SHOW SLAVE STATUS ではなく SHOW REPLICA STATUS を使用していました。10.5 より前の MariaDB バージョン、または 8.0.23 より前の MySQL バージョンを使用している場合は、SHOW SLAVE STATUS を使用します。

ReplicaLag メトリクスが 0 に達すると、レプリカはプライマリ DB インスタンスに追いついています。ReplicaLag メトリクスにより -1 が返された場合、レプリケーションは現在アクティブではありません。ReplicaLag = -1Seconds_Behind_Master = NULL と同等です。

Oracle で、ReplicaLag メトリクスは、Apply Lag 値と、現在の時刻と適用するラグの DATUM_TIME 値の差異の合計です。DATUM_TIME 値は、リードレプリカがソース DB インスタンスから最後にデータを受信した時刻です。詳細については、Oracle ドキュメントの「V$DATAGUARD_STATS」を参照してください。

SQL Server の場合、ReplicaLag メトリクスは、遅延しているデータベースの最大ラグ (秒単位) です。例えば、5 秒遅れているデータベースと 10 秒遅れているデータベースがある場合、ReplicaLag は 10 秒です。ReplicaLag メトリクスは、次のクエリの値を返します。

SELECT MAX(secondary_lag_seconds) max_lag FROM sys.dm_hadr_database_replica_states;

詳細については、Microsoft ドキュメントの「secondary_lag_seconds」を参照してください。

ReplicaLag はレプリカのセットアップ中やリードレプリカが -1 状態にあるときなど、RDS でラグを確認できない場合は error を返します。

注記

新しいデータベースは、リードレプリカでアクセス可能になるまでラグ計算に含まれません。

PostgreSQL では、ReplicaLag メトリクスは次のクエリの値を返します。

SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS reader_lag

PostgreSQL バージョン 9.5.2 以降では、ソースインスタンスで保持される先書きログ (WAL) の管理に物理レプリケーションスロットを使用します。クロスリージョンリードレプリカインスタンスごとに、Amazon RDS は物理レプリケーションスロットを作成し、インスタンスに関連付けます。2 つ Amazon CloudWatch メトリクス Oldest Replication Slot LagTransaction Logs Disk Usage では、WAL データの受信について最も長い遅延が発生しているレプリカまでの距離と、WAL データに使用されているストレージの量が表示されます。クロスリージョンリードレプリカで著しい遅延が発生しているときは、Transaction Logs Disk Usage の値を大幅に増やすことができます。

CloudWatch を使用した DB インスタンスのモニタリングの詳細については、「Amazon CloudWatch を使用した Amazon RDS メトリクスのモニタリング」を参照してください。

別の AWS リージョン でのリードレプリカの作成

Amazon RDS では、リードレプリカをソース DB インスタンスとは異なる AWS リージョン に作成できます。


                クロスリージョンリードレプリカの設定

別の AWS リージョン にリードレプリカを作成して、以下を実行します。

  • 災害対策機能が向上します。

  • ユーザーに近い AWS リージョン への読み取りオペレーションをスケールします。

  • ある AWS リージョン のデータセンターから別の AWS リージョン のデータセンターへの移行が簡単になります。

ソースインスタンスとは異なる AWS リージョン でリードレプリカを作成する作業は、同じ AWS リージョン でレプリカを作成する作業と似ています。AWS Management Console の使用、create-db-instance-read-replica コマンドの実行、または CreateDBInstanceReadReplica API オペレーションの呼び出しを行うことができます。

注記

ソース DB インスタンスとは異なる AWS リージョン に暗号化されたリードレプリカを作成するには、ソース DB インスタンスを暗号化する必要があります。

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

機能の可用性とサポートは、各データベースエンジンの特定のバージョン、および AWS リージョン によって異なります。リージョン間レプリケーションによるバージョンとリージョンの可用性の詳細については、「クロスリージョンリードレプリカ」を参照してください。

クロスリージョンリードレプリカの作成

異なる AWS リージョン でソース MariaDB、Microsoft SQL Server、MySQL、Oracle、または PostgreSQL DB インスタンスからリードレプリカを作成する手順を以下に示します。

AWS Management Console を使用して、複数の AWS リージョン にわたるリードレプリカを作成できます。

複数の AWS リージョン にわたるリードレプリカをコンソールで作成するには
  1. AWS Management Consoleにサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[データベース] を選択します。

  3. リードレプリカのソースとして使用する MariaDB、Microsoft SQL Server、MySQL、Oracle、または PostgreSQL DB インスタンスを選択します。

  4. [アクション] で [リードレプリカの作成] を選択します。

  5. [DB インスタンス識別子] に、リードレプリカの名前を入力します。

  6. [送信先リージョン] を選択します。

  7. 使用するインスタンス仕様を選択します。リードレプリカでも同等以上の DB インスタンスクラスとストレージタイプを使用することをお勧めします。

  8. 別の AWS リージョン で暗号化されたリードレプリカを作成するには

    1. [暗号化の有効化] を選択します。

    2. [AWS KMS key] では、作成先 AWS リージョン の KMS キーの AWS KMS key 識別子を選択します。

    注記

    暗号化されたリードレプリカを作成するには、ソース DB インスタンスを暗号化する必要があります。DB インスタンスの暗号化については、「Amazon RDS リソースの暗号化」を参照してください。

  9. ストレージの自動スケーリングなど、他のオプションを選択します。

  10. [Create read replica] を選択します。

異なる AWS リージョン でソースの MySQL、Microsoft SQL Server、MariaDB、Oracle、または PostgreSQL DB インスタンスからリードレプリカを作成するには、create-db-instance-read-replica コマンドを使用できます。この場合、リードレプリカ (作成先のリージョン) が必要な AWS リージョン の create-db-instance-read-replica を使用し、ソース DB インスタンスの Amazon リソースネーム (ARN) を指定します。ARN は、Amazon Web Services で作成したリソースを一意に識別します。

例えば、ソース DB インスタンスが US East (N. Virginia) リージョンにある場合、ARN は次の例のようになります。

arn:aws:rds:us-east-1:123456789012:db:mydbinstance

ARN の詳細については、「Amazon RDS の Amazon リソースネーム (ARN) の使用」を参照してください。

ソース DB インスタンスから異なる AWS リージョン にリードレプリカを作成するには、作成先の AWS リージョン で AWS CLI create-db-instance-read-replica コマンドを使用します。別の AWS リージョン でリードレプリカを作成するには、次のパラメータが必要です。

  • --region – リードレプリカが作成される作成先の AWS リージョン。

  • --source-db-instance-identifier – ソース DB インスタンスの DB インスタンス識別子です。この識別子は、コピー元 AWS リージョン の ARN 形式である必要があります。

  • --db-instance-identifier – 作成先の AWS リージョン のリードレプリカの識別子。

例 クロスリージョンリードレプリカの

次のコードは、米国西部 (オレゴン) リージョン内のソース DB インスタンスから US East (N. Virginia) リージョン内にリードレプリカを作成します。

Linux、macOS、Unix の場合:

aws rds create-db-instance-read-replica \ --db-instance-identifier myreadreplica \ --region us-west-2 \ --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:mydbinstance

Windows の場合:

aws rds create-db-instance-read-replica ^ --db-instance-identifier myreadreplica ^ --region us-west-2 ^ --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:mydbinstance

別の AWS リージョン で暗号化されたリードレプリカを作成するには、次のパラメータも必要です。

  • --kms-key-id - 作成先 AWS リージョン でリードレプリカの暗号化に使用する KMS キーの AWS KMS key 識別子。

例 暗号化されたクロスリージョンリードレプリカの

次のコードは、米国西部 (オレゴン) リージョン内のソース DB インスタンスから US East (N. Virginia) リージョン内に暗号化されたリードレプリカを作成します。

Linux、macOS、Unix の場合:

aws rds create-db-instance-read-replica \ --db-instance-identifier myreadreplica \ --region us-west-2 \ --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:mydbinstance \ --kms-key-id my-us-west-2-key

Windows の場合:

aws rds create-db-instance-read-replica ^ --db-instance-identifier myreadreplica ^ --region us-west-2 ^ --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:mydbinstance ^ --kms-key-id my-us-west-2-key

--source-region オプションは、AWS GovCloud (米国東部) と AWS GovCloud (米国西部) リージョン間で暗号化されたリードレプリカを作成する場合に必要です。--source-region には、ソース DB インスタンスの AWS リージョン を指定します。

--source-region を指定しない場合、--pre-signed-url の値を指定する必要があります。署名付きの URL は、ソースの AWS リージョン で呼び出される create-db-instance-read-replica コマンドに対する、署名バージョン 4 で署名されたリクエストを含む URL です。pre-signed-url オプションの詳細については、AWS CLI コマンドリファレンスの「create-db-instance-read-replica」を参照してください。

異なる AWS リージョン でソースの MySQL、Microsoft SQL Server、MariaDB、Oracle、または PostgreSQL DB インスタンスからリードレプリカを作成するには、Amazon RDS API オペレーション CreateDBInstanceReadReplica を呼び出すことができます。この場合、リードレプリカが必要な AWS リージョン (作成先のリージョン) の CreateDBInstanceReadReplica を呼び出し、ソース DB インスタンスの Amazon リソースネーム (ARN) を指定します。ARN は、Amazon Web Services で作成したリソースを一意に識別します。

ソース DB インスタンスから異なる AWS リージョン に暗号化されたリードレプリカを作成するには、作成先の AWS リージョン で Amazon RDS API の CreateDBInstanceReadReplica オペレーションを使用できます。暗号化されたリードレプリカを別の AWS リージョン に作成するには、PreSignedURL の値を指定する必要があります。PreSignedURL には、リードレプリカが作成されるソース AWS リージョン で呼び出す CreateDBInstanceReadReplica オペレーションのリクエストが含まれている必要があります。PreSignedUrl の詳細については、「CreateDBInstanceReadReplica」を参照してください。

例えば、ソース DB インスタンスが US East (N. Virginia) リージョンにある場合、ARN は以下のような内容です。

arn:aws:rds:us-east-1:123456789012:db:mydbinstance

ARN の詳細については、「Amazon RDS の Amazon リソースネーム (ARN) の使用」を参照してください。

https://us-west-2.rds.amazonaws.com/ ?Action=CreateDBInstanceReadReplica &KmsKeyId=my-us-east-1-key &PreSignedUrl=https%253A%252F%252Frds.us-west-2.amazonaws.com%252F %253FAction%253DCreateDBInstanceReadReplica %2526DestinationRegion%253Dus-east-1 %2526KmsKeyId%253Dmy-us-east-1-key %2526SourceDBInstanceIdentifier%253Darn%25253Aaws%25253Ards%25253Aus-west-2%123456789012%25253Adb%25253Amydbinstance %2526SignatureMethod%253DHmacSHA256 %2526SignatureVersion%253D4%2526SourceDBInstanceIdentifier%253Darn%25253Aaws%25253Ards%25253Aus-west-2%25253A123456789012%25253Ainstance%25253Amydbinstance %2526Version%253D2014-10-31 %2526X-Amz-Algorithm%253DAWS4-HMAC-SHA256 %2526X-Amz-Credential%253DAKIADQKE4SARGYLE%252F20161117%252Fus-west-2%252Frds%252Faws4_request %2526X-Amz-Date%253D20161117T215409Z %2526X-Amz-Expires%253D3600 %2526X-Amz-SignedHeaders%253Dcontent-type%253Bhost%253Buser-agent%253Bx-amz-content-sha256%253Bx-amz-date %2526X-Amz-Signature%253D255a0f17b4e717d3b67fad163c3ec26573b882c03a65523522cf890a67fca613 &DBInstanceIdentifier=myreadreplica &SourceDBInstanceIdentifier=&region-arn;rds:us-east-1:123456789012:db:mydbinstance &Version=2012-01-15 &SignatureVersion=2 &SignatureMethod=HmacSHA256 &Timestamp=2012-01-20T22%3A06%3A23.624Z &AWSAccessKeyId=<&AWS; Access Key ID> &Signature=<Signature>

Amazon RDS でのクロスリージョンレプリケーションのしくみ

Amazon RDS は、次のプロセスを使用してクロスリージョンリードレプリカを作成します。関係する AWS リージョン とデータベースのデータ量によっては、このプロセスは完了までに数時間かかることがあります。クロスリージョンリードレプリカを作成する際、この情報を使用してプロセスの進行状況を確認できます。

  1. Amazon RDS は、ソース DB インスタンスをレプリケーションソースとして設定し始め、ステータスを modifying に設定します。

  2. Amazon RDS は、作成先の AWS リージョン で指定されたリードレプリカをセットアップし始め、ステータスを creating に設定します。

  3. Amazon RDS は、ソース AWS リージョン でソース DB インスタンスの自動 DB スナップショットを作成します。DB スナップショット名の形式は、rds:<InstanceID>-<timestamp> です。ここで、<InstanceID> はソースインスタンスの識別子で、<timestamp> はコピーの開始日時です。例えば、rds:mysourceinstance-2013-11-14-09-24 はインスタンス mysourceinstance から 2013-11-14-09-24 に作成されたことを表します。自動 DB スナップショットの作成中、ソース DB インスタンスのステータスが modifying のままになり、リードレプリカのステータスが creating のままになります。DB スナップショットのステータスは creating です。コンソールの DB スナップショットページの進行状況列には、DB スナップショット作成の進行状況が報告されます。DB スナップショットが完成すると、DB スナップショットとソース DB インスタンスの両方のステータスが available に設定されます。

  4. Amazon RDS は、初期データ転送用のクロスリージョンスナップショットコピーを開始します。スナップショットコピーは、転送先 AWS リージョン の自動スナップショットとして、creating のステータスで一覧表示されます。名前はソース DB スナップショットと同じです。DB スナップショットの進行状況列には、コピーの進行状況が示されます。コピーが完了すると、DB スナップショットコピーのステータスが available に設定されます。

  5. 次に、Amazon RDS はリードレプリカで初期データロード用のコピーされた DB スナップショットを使用します。このフェーズの間、リードレプリカは転送先の DB インスタンスの一覧に、creating のステータスで表示されます。ロードが完了すると、リードレプリカのステータスが available に設定され、DB スナップショットコピーが削除されます。

  6. リードレプリカが available ステータスに達すると、Amazon RDS は、リードレプリカ作成操作が開始されてからソースインスタンスに加えられた変更のレプリケーションから始めます。このフェーズでは、リードレプリカのレプリケーション遅延時間が 0 より大きくなります。

    レプリケーションのラグタイムについては、「リードレプリケーションのモニタリング」を参照してください。

クロスリージョンレプリケーションに関する考慮事項

AWS リージョン 内でレプリケーションを実行する際の考慮事項はすべて、クロスリージョンレプリケーションに適用されます。AWS リージョン 間のレプリケーションには、他にも次の考慮事項が適用されます。

  • ソース DB インスタンスでは、複数の AWS リージョン にクロスリージョンリードレプリカを作成できます。

  • GovCloud (米国東部) と GovCloud (米国西部) のリージョンの間ではレプリケーションできますが、GovCloud (米国) との間ではレプリケーションできません。

  • Microsoft SQL Server、Oracle、および PostgreSQL DB インスタンスの場合、他の Amazon RDS DB インスタンスのリードレプリカではないソース Amazon RDS DB インスタンスから、リージョン間の Amazon RDS リードレプリカのみを作成することができます。この制限は MariaDB および MySQL DB インスタンスには適用されません。

  • リードレプリカがソースインスタンスとは異なる AWS リージョン にある場合は、高いレベルのラグタイムが発生することが予想されます。リージョンのデータセンター間のネットワークチャネルの方が長くなったために、このようなラグタイムが発生します。

  • クロスリージョンリードレプリカでは、--db-subnet-group-name パラメータを指定する create read replica コマンドのいずれかで、同じ VPC の DB サブネットグループを指定する必要があります。

  • ソース VPC のアクセスコントロールリスト (ACL) のエントリ数に制限があるため、5 つを超えるクロスリージョンリードレプリカのインスタンスについては保証されません。

  • 多くの場合、リードレプリカでは、指定された DB エンジンのデフォルトの DB パラメータグループおよび DB オプショングループが使用されます。

    MySQL および Oracle DB エンジンの場合、リードレプリカのカスタムパラメータグループを AWS CLI コマンド create-db-instance-read-replica--db-parameter-group-name オプションで指定することができます。AWS Management Console を使用している場合、カスタムパラメータグループを指定することはできません。

  • リードレプリカは、デフォルトのセキュリティグループを使用します。

  • MariaDB、Microsoft SQL Server、MySQL、Oracle DB の各インスタンスの場合、クロスリージョンリードレプリカのソース DB インスタンスが削除されると、リードレプリカが昇格します。

  • PostgreSQL DB インスタンスの場合、クロスリージョンリードレプリカのソース DB インスタンスが削除されると、レプリケーションのステータスは terminated に設定されます。リードレプリカは昇格しません。

    リードレプリカを手動で昇格させるか、削除する必要があります。

クロスリージョンリードレプリカのリクエスト

ソースリージョンと通信してクロスリージョンリードレプリカの作成をリクエストするには、リクエスタ (IAM ロールまたは IAM ユーザー) がソース DB インスタンスとソースリージョンへのアクセス権を持っている必要があります。

リクエスタの IAM ポリシーの特定の条件により、リクエストが失敗する可能性があります。次の例では、ソース DB インスタンスが 米国東部 (オハイオ) にあり、リードレプリカが US East (N. Virginia) に作成されていることを前提としています。これらの例は、リクエストが失敗する原因となるリクエスタの IAM ポリシー内の条件を示しています。

  • リクエスタのポリシーには、aws:RequestedRegion の条件があります。

    ... "Effect": "Allow", "Action": "rds:CreateDBInstanceReadReplica", "Resource": "*", "Condition": { "StringEquals": { "aws:RequestedRegion": "us-east-1" } }

    ポリシーが出典リージョンへのアクセスを許可していないため、リクエストは失敗します。リクエストを正常に実行するには、ソースリージョンとコピー先リージョンの両方を指定します。

    ... "Effect": "Allow", "Action": "rds:CreateDBInstanceReadReplica", "Resource": "*", "Condition": { "StringEquals": { "aws:RequestedRegion": [ "us-east-1", "us-east-2" ] } }
  • リクエスタのポリシーでは、ソース DB インスタンスへのアクセスが許可されていません。

    ... "Effect": "Allow", "Action": "rds:CreateDBInstanceReadReplica", "Resource": "arn:aws:rds:us-east-1:123456789012:db:myreadreplica" ...

    リクエストを正常に実行するには、ソースインスタンスとレプリカの両方を指定します。

    ... "Effect": "Allow", "Action": "rds:CreateDBInstanceReadReplica", "Resource": [ "arn:aws:rds:us-east-1:123456789012:db:myreadreplica", "arn:aws:rds:us-east-2:123456789012:db:mydbinstance" ] ...
  • リクエスターのポリシーが aws:ViaAWSService を拒否します。

    ... "Effect": "Allow", "Action": "rds:CreateDBInstanceReadReplica", "Resource": "*", "Condition": { "Bool": {"aws:ViaAWSService": "false"} }

    出典リージョンとの通信は、リクエスタに代わって RDS によって行われます。リクエストを正常に実行するには、AWS のサービスからの呼び出しを拒否しないでください。

  • リクエスタのポリシーには、aws:SourceVpc または aws:SourceVpce の条件があります。

    RDS がリモートリージョンへの呼び出しを行うとき、指定された VPC または VPC エンドポイントからの呼び出しではないため、これらのリクエストは失敗する可能性があります。

リクエストが失敗する原因となる前述の条件のいずれかを使用する必要がある場合は、ポリシーに aws:CalledVia とともに 2 番目のステートメントを含めて、リクエストを成功させることができます。例えば、次のように aws:CalledViaaws:SourceVpce を使用できます。

... "Effect": "Allow", "Action": "rds:CreateDBInstanceReadReplica", "Resource": "*", "Condition": { "Condition" : { "ForAnyValue:StringEquals" : { "aws:SourceVpce": "vpce-1a2b3c4d" } } }, { "Effect": "Allow", "Action": [ "rds:CreateDBInstanceReadReplica" ], "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:CalledVia": [ "rds.amazonaws.com" ] } } }

詳細については、IAM ユーザーガイド の 「IAM のポリシーとアクセス許可」を参照してください。

リードレプリカの承認

クロスリージョン DB のリードレプリカ作成リクエストが success を返した後、RDS はバックグラウンドでレプリカの作成を開始します。RDS がソース DB インスタンスにアクセスするための承認が作成されます。この承認は、ソース DB インスタンスをリードレプリカにリンクし、RDS が指定されたリードレプリカにのみコピーできるようにします。

承認は、サービスにリンクされた IAM ロールの rds:CrossRegionCommunication アクセス許可を使用して RDS によって検証されます。レプリカが承認されると、RDS はソースリージョンと通信し、レプリカの作成を完了します。

RDS は、CreateDBInstanceReadReplica リクエストによって以前に承認されていない DB インスタンスにアクセスできません。リードレプリカの作成が完了すると、承認は取り消されます。

RDS は、サービスリンクされたロールを使用して、ソースリージョンでの承認を確認します。レプリケーション作成プロセス中にサービスリンクされたロールを削除すると、作成は失敗します。

詳細については、IAM ユーザーガイドの「サービスにリンクされたロールの使用」を参照してください。

AWS Security Token Service 認証情報の使用

グローバル AWS Security Token Service (AWS STS) エンドポイントからのセッショントークンは、デフォルトで有効になっている AWS リージョン (商用リージョン) でのみ有効です。assumeRole の AWS STS API 操作からの認証情報を使用する場合、出典リージョンがオプトインリージョンである場合は、そのリージョンのエンドポイントを使用します。それ以外の場合、このリクエストは失敗します。これは、認証情報が両方のリージョンで有効である必要があるために発生します。これは、そのリージョンの AWS STS エンドポイントが使用されている場合にのみオプトインリージョンに当てはまります。

グローバルエンドポイントを使用するには、オペレーションで両方のリージョンで有効になっていることを確認します。Valid in all AWS リージョン アカウント設定でグローバルエンドポイントを AWS STS に設定します。

署名付き URL パラメータの認証情報にも同じルールが適用されます。

詳細については、IAM ユーザーガイドの 「AWS リージョン での AWS STS の管理」を参照してください。

クロスリージョンレプリケーションのコスト

クロスリージョンレプリケーションから転送されたデータには、Amazon RDS のデータ転送料金が発生します。以下のクロスリージョンレプリケーションアクションでは、ソース AWS リージョン から転送されるデータに対して料金が発生します。

  • リードレプリカを作成すると、Amazon RDS によりソースインスタンスのスナップショットが作成され、リードレプリカ AWS リージョン にスナップショットが転送されます。

  • ソースデータベースのデータに変更が加えられるたびに、Amazon RDS によりソース AWS リージョン からリードレプリカ AWS リージョン にデータが転送されます。

データ転送料金の詳細については、「Amazon RDS の料金」を参照してください。

MySQL および MariaDB インスタンスの場合、作成するクロスリージョンリードレプリカの数を減らすことで、データ転送コストを削減できます。例えば、1 つの AWS リージョン にソース DB インスタンスがあり、別の AWS リージョン に 3 つのリードレプリカが必要であるとします。この場合、ソース DB インスタンスからリードレプリカを 1 つのみ作成します。他の 2 つのレプリカは、ソース DB インスタンスからではなく、最初のリードレプリカから作成します。

例として、ある AWS リージョン に source-instance-1 がある場合は、次のようにできます。

  • ソースとして source-instance-1 を指定して、新しい AWS リージョン に read-replica-1 を作成します。

  • read-replica-2 から read-replica-1 を作成します。

  • read-replica-3 から read-replica-1 を作成します。

この例では、source-instance-1 から read-replica-1 に転送されるデータ対してのみ課金されます。read-replica-1 から他の 2 つのレプリカに転送されたデータには課金されません。すべて同じ AWS リージョン にあるためです。3 つのレプリカをすべて source-instance-1 から直接作成した場合、3 つのレプリカすべてへのデータ転送に課金されます。