リードレプリカの使用 - Amazon Relational Database Service

リードレプリカの使用

Amazon RDS は、MariaDB、Microsoft SQL Server、MySQL、Oracle、PostgreSQL の DB エンジンに組み込まれたレプリケーション機能を使用して、リードレプリカと呼ばれる特殊なタイプの DB インスタンスをソース DB インスタンスから作成します。ソース DB インスタンスがプライマリ DB インスタンスになります。プライマリ DB インスタンスに対して行った更新は、リードレプリカに非同期的にコピーされます。読み込みクエリをアプリケーションからリードレプリカにルーティングすることにより、プライマリ DB インスタンスの負荷を軽減できます。リードレプリカを使うと、単一 DB インスタンスのキャパシティ制約にとらわれることなく伸縮自在にスケールアウトし、読み込み負荷の高いデータベースワークロードに対応できます。


            リードレプリカの設定
注記

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

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

注記

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

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

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


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

高可用性レプリカとスタンバイレプリカの詳細については、「Amazon RDS での高可用性 (マルチ AZ)」を参照してください。

リードレプリカは、MariaDB、Microsoft SQL Server、MySQL、Oracle、PostgreSQL DB エンジンによりサポートされています。このセクションでは、これらのすべてのエンジンでのリードレプリカの使用に関する一般的な情報について説明します。特定のエンジンでのリードレプリカの使用については、以下のセクションを参照してください。

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

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

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

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

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

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

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

ソース DB インスタンスストレージのタイプ ソース DB インスタンスストレージの割り当て リードレプリカのストレージタイプのオプション
PIOPS 100 GiB – 32 TiB PIOPS、GP2、Standard
GP2 100 GiB – 32 TiB PIOPS、GP2、Standard
GP2 100 GiB 未満 GP2、Standard
Standard 100 GiB~6 TiB PIOPS、GP2、Standard
Standard 100 GiB 未満 GP2、Standard
注記

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

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

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

異なる 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 リードレプリカは物理コピーであり、同様に書き込み可能にすることはできません。リードレプリカを昇格させて書き込み可能にすることができます。昇格したリードレプリカには、昇格をリクエストされた時点までのレプリケートされたデータがあります。

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

はい。MySQL または MariaDB リードレプリカでは、自動バックアップを実行できます。

いいえ。Amazon RDS for Oracle リードレプリカの手動スナップショットを作成したり、自動バックアップを有効にしたりすることはできません。

はい、PostgreSQL リードレプリカの手動スナップショットは作成できますが、自動バックアップを有効にすることはできません。

いいえ。Amazon RDS for SQL Server リードレプリカの手動スナップショットを作成したり、自動バックアップを有効にしたりすることはできません。

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

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

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

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

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

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

いいえ。

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

いいえ。

いいえ。

リードレプリカの作成

AWS マネジメントコンソール、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 インスタンスであるリードレプリカにも適用されます。MySQL DB インスタンスの場合、自動バックアップは、MySQL 5.6 以降 (MySQL バージョン 5.5 は対象外) を実行するリードレプリカでのみサポートされます。RDS for MySQL バージョン 5.6 以降のリードレプリカで自動バックアップを有効にするには、まずリードレプリカを作成し、次にこのリードレプリカを変更して自動バックアップを有効にします。

注記

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

ソース DB インスタンスとは異なる AWS アカウントにリードレプリカを作成することはできません。

ソース DB インスタンスからリードレプリカを作成するには

  1. AWS マネジメントコンソールにサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

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

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

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

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

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

  7. [Multi-AZ deployment] で [Yes] を選択して、レプリカのフェイルオーバーをサポートするために別のアベイラビリティーゾーンにレプリカのスタンバイを作成します。

    注記

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

  8. 暗号化されたリードレプリカを作成するには

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

    2. [Master key (マスターキー)] で、カスタマーマスターキー (CMK) の AWS Key Management Service (AWS KMS) キー識別子を選択します。

    注記

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

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

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

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

ソース DB インスタンスからリードレプリカを作成するには、AWS CLI コマンド create-db-instance-read-replica を使用します。この例では、ストレージの自動スケーリングも有効にします。

Linux、macOS、Unix の場合:

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

Windows の場合:

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

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

  • DBInstanceIdentifier

  • SourceDBInstanceIdentifier

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

リードレプリカをスタンドアロン DB インスタンスに昇格させることができます。リードレプリカを昇格させると、使用可能になる前に DB インスタンスが再起動されます。


                リードレプリカの昇格

リードレプリカをスタンドアロン DB インスタンスに昇格させるのには、いくつかの理由があります。

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

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

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

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

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

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

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

リードレプリカを昇格させると、作成した新しい DB インスタンスは、前のリードレプリカのオプショングループとパラメータグループを保持します。リードレプリカのサイズによっては、昇格プロセスが完了するまで数分以上かかる場合があります。リードレプリカを新しい DB インスタンスに昇格させると、他の DB インスタンスと同等になります。たとえば、新しい DB インスタンスからリードレプリカを作成して、特定時点への復元オペレーションを実行できます。昇格した DB インスタンスはリードレプリカではなくなったため、レプリケーションターゲットとしては使用できません。ソース DB インスタンスに複数のリードレプリカがある場合、いずれかのリードレプリカを DB インスタンスに昇格させても、他のレプリカには影響が及びません。

バックアップ期間は、以前のバックアップ以降のデータベースに対する変更数の関数です。リードレプリカをスタンドアロンインスタンスに昇格させる場合は、昇格させる前にバックアップを有効にし、少なくとも 1 つのバックアップを完了することをお勧めします。また、リードレプリカが backing-up 状態にある場合は、スタンドアロンインスタンスに昇格させることはできません。リードレプリカでバックアップを有効にしている場合は、自動バックアップウィンドウを構成して、毎日のバックアップがリードレプリカの昇格を妨げないようにします。

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

  1. プライマリ DB インスタンスに対するトランザクションの書き込みを停止し、すべての更新がリードレプリカに反映されるまで待ちます。データベースの更新は、プライマイ DB インスタンスで行われた後にリードレプリカで行われ、このレプリケーションラグは大きく変動する場合があります。Replica Lag メトリクスを使用して、リードレプリカに対するすべての更新の時期を確認できます。

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

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

    注記

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

  4. (オプション) 新しい DB インスタンスをマルチ AZ 配置に変更します。詳細については、「Amazon RDS DB インスタンスを変更する」および「Amazon RDS での高可用性 (マルチ AZ)」を参照してください。

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

  1. AWS マネジメントコンソールにサインインし、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 コンソールは、リードレプリカの詳細の [可用性と耐久性] セクションにリードレプリカのステータスを表示します。リードレプリカの詳細を表示するには、Amazon RDS コンソールのインスタンスのリストでリードレプリカの名前を選択します。


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

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

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

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

  • replication degraded (SQL Server のみ) – レプリカはプライマリインスタンスからデータを受信していますが、1 つ以上のデータベースが更新を取得していない可能性があります。これは、レプリカが新しく作成されたデータベースをセットアップしているときなどに発生します。

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

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

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

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

  • 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 メトリクスを表示します。

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

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

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

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

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 ag.name name, MAX(hdrs.secondary_lag_seconds) max_lag from sys.dm_hadr_database_replica_state

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

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

注記

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

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 メトリクスのモニタリング」を参照してください。