メニュー
Amazon Relational Database Service
ユーザーガイド (API Version 2014-10-31)

PostgreSQL、MySQL、および MariaDB リードレプリカの使用

Amazon RDS は、MySQL、MariaDB、および PostgreSQL (バージョン 9.3.5 以降) DB エンジンに組み込まれたレプリケーション機能を使用して、リードレプリカと呼ばれる特殊なタイプの DB インスタンスをソース DB インスタンスから作成します。ソース DB インスタンスに加えられた更新は、リードレプリカに非同期的にコピーされます。読み込みクエリをアプリケーションからリードレプリカにルーティングすることにより、ソース DB インスタンスへの負荷を減らすことができます。リードレプリカを使うと、読み込み負荷の高いデータベースワークロードに単一 DB インスタンスの能力が対応しきれない場合に、弾力的にスケールアウトできます。

注記

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

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

Amazon RDS は、リードレプリカがソース DB インスタンスとは別の AWS リージョンにある場合、その DB インスタンスとリードレプリカとの間にセキュアな通信チャンネルを設定します。Amazon RDS は、セキュリティグループエントリの追加など、安全なチャネルを有効にするために必要な AWS セキュリティ設定を確立します。PostgreSQL DB インスタンスは、ソースとレプリカの両方のインスタンスについて、ssl パラメータを 1 に設定することで暗号化できる安全な接続を使用します。

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

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

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

  • ソース DB インスタンスが利用可能でない場合に読み込みトラフィックを誘導します。ソース DB インスタンスが入出力リクエストを取得できない場合 (バックアップまたは定期メンテナンスによる入出力一時停止などのため)、読み込みトラフィックをリードレプリカに誘導することができます。このようなユースケースの場合、ソース DB インスタンスを利用できないため、リードレプリカのデータは「古い」場合があるため注意が必要です。

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

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

ソース DB インスタンスのストレージタイプ ソース DB インスタンスのストレージ割り当て リードレプリカのストレージタイプオプション
PIOPS 100 GB〜3 TB PIOPS | GP2 | Standard
GP2 100 GB〜3 TB PIOPS | GP2 | Standard
GP2 100 GB 未満 GP2 | Standard
スタンダード 100 GB〜3 TB PIOPS | GP2 | Standard
スタンダード 100 GB 未満 GP2 | Standard

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

MySQL、MariaDB、および PostgreSQL リードレプリカの場合、Amazon RDS の ReplicaLag メトリクスを表示することで、Amazon CloudWatch でのレプリケーション遅延をモニタリングできます。MySQL と MariaDB の場合、ReplicaLag メトリクスでは、SHOW SLAVE STATUS コマンドの Seconds_Behind_Master フィールドの値がレポートされます。PostgreSQL の場合、ReplicaLag メトリクスでは SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS slave_lag の値がレポートされます。

MySQL と MariaDB のレプリケーション遅延の一般的な原因は以下のとおりです。

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

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

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

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

PostgreSQL リードレプリカと MySQL または MariaDB リードレプリカの違い

PostgreSQL DB エンジンと MySQL および MariaDB DB エンジンのレプリケーションの実装方法は異なるため、大きな違いがいくつかあります。次の表を参照してください。

機能/動作 PostgreSQL MySQL と MariaDB

レプリケーション方法

物理レプリケーション。 

論理レプリケーション。

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

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

Amazon RDS では、適用されていないバイナリログは削除されません。

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

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

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

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

はい、PostgreSQL リードレプリカのスナップショットを作成できますが、自動バックアップは実行できません。

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

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

いいえ。PostgreSQL では 1 つのプロセスでレプリケーションを処理できます。

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

PostgreSQL リードレプリカ (バージョン 9.3.5 以降)

Amazon RDS PostgreSQL 9.3.5 以降では PostgreSQL ネイティブストリーミングレプリケーションを使用して、ソース (PostgreSQL 用語では "マスター") DB インスタンスの読み取り専用コピーを作成します。このリードレプリカ (PostgreSQL 用語では "スタンバイ") DB インスタンスは、マスター DB インスタンスの非同期的に作成された物理レプリケーションです。これは、ソース DB インスタンスとリードレプリカ間で先書きログ (WAL) データを送信する特別な接続によって作成されます。この接続では、PostgreSQL により、データベースに変更が発生したときにその変更が非同期的にストリーミングされます。

PostgreSQL は "レプリケーション" ロールを使用して、ストリーミングレプリケーションを実行します。このロールには特権がありますが、データの変更には使用できません。PostgreSQL ではレプリケーション処理に 1 つのプロセスを使用します。

PostgreSQL リードレプリカを作成する際に、マスター DB インスタンスを停止する必要はありません。Amazon RDS では、サービスを中断することなく、ソース DB インスタンスとリードレプリカに必要なパラメータおよびアクセス権限が設定されます。ソース DB インスタンスのスナップショットが作成され、このスナップショットがリードレプリカになります。リードレプリカの削除時にも停止は発生しません。

1 つのソース DB インスタンスから最大 5 つのリードレプリカを作成できます。レプリケーションを効率的に実行するには、各リードレプリカに、ソース DB インスタンスと同程度の計算およびストレージリソースが必要です。ソース DB インスタンスを拡張した場合、リードレプリカも拡張する必要があります。

互換性のないパラメータがあり、それが原因でリードレプリカを起動できない場合、Amazon RDS によってリードレプリカでのパラメータ値が上書きされます。たとえば、リードレプリカよりもソース DB インスタンスでの max_connections パラメータ値が大きい場合、Amazon RDS により、リードレプリカのパラメータがソース DB インスタンスのパラメータと同じ値になるように更新されます。

次に、PostgreSQL リードレプリカに関して知っておくべき重要事項を示します。

  • PostgreSQL リードレプリカは読み取り専用で、書き込み可能にすることはできません。

  • リードレプリカからリードレプリカを作成することはできません (つまり、カスケードリードレプリカを作成することはできません)。

  • PostgreSQL リードレプリカを、新しいソース DB インスタンスに昇格させることができます。ただし、リードレプリカを自動的に新しいソース DB インスタンスにすることはできません。昇格した場合、リードレプリカは WAL 通信の受信を停止し、読み取り専用インスタンスではなくなります。昇格したリードレプリカは新しいソース DB インスタンスになるため、先に進むにはレプリケーションをセットアップする必要があります。

  • ソース DB インスタンスでユーザートランザクションが発生していない場合、PostgreSQL リードレプリカでは、最長 5 分のレプリケーションの遅延が報告されます。

  • DB インスタンスがソース DB インスタンスとして機能するには、バックアップ保持期間を 0 以外の値に設定することにより、ソース DB インスタンスで自動バックアップを有効にする必要があります。

PostgreSQL レプリケーションを中断させる状況

場合によっては、PostgreSQL ソース DB インスタンスによって、リードレプリカでレプリケーションが意図せず中断されることがあります。たとえば、次のような状況が考えられます。

  • max_wal_senders パラメータの設定が低すぎるため、リードレプリカの数に対して十分なデータを提供できない場合。この状況では、レプリケーションが停止します。

  • データをリードレプリカに提供するために保持する WAL ファイルの数は、PostgreSQL パラメータ、wal_keep_segments で指定します。 パラメータ値は、保持するログの数を指定します。パラメータ値の設定が低すぎると、リードレプリカでのストリーミングに大幅な遅延が発生し、レプリケーションが停止します。この場合、Amazon RDS によりレプリケーションエラーが報告され、ソース DB インスタンスのアーカイブされた WAL ログの再生によってリードレプリカで復旧が開始されます。この復旧プロセスは、レプリケーションのストリーミングを続行するのに十分なだけリードレプリカの遅延が解消されるまで続きます。このプロセスの詳細および適切なパラメータ設定の決定方法については、「PostgreSQL リードレプリカに関する問題のトラブルシューティング」を参照してください。

  • ソース DB インスタンスのエンドポイントが変化した場合。この状況では、PostgreSQL リードレプリカの再起動が必要になります。

リードレプリカにデータを提供する WAL ストリームが破損した場合、PostgreSQL は復旧モードに切り替えて、アーカイブされた WAL ファイルを使用してリードレプリカを保存します。このプロセスが完了すると、PostgreSQL によりストリーミングレプリケーションの再構築が試行されます。

MySQL および MariaDB リードレプリカ

MySQL または MariaDB DB インスタンスがレプリケーションソースとして機能するには、バックアップ保持期間を 0 以外の値に設定することにより、ソース DB インスタンスで自動バックアップを有効にする必要があります。この要件は、別のリードレプリカのソース DB インスタンスであるリードレプリカにも適用されます。自動バックアップは、MariaDB のすべてのバージョン、または MySQL 5.6 以降を実行するリードレプリカでのみサポートされます。

MySQL と MariaDB の両方インスタンスのバイナリログの調整に基づいて、レプリケーションを設定できます。MariaDB インスタンスでは、グローバルトランザクション ID (GTIDs) に基づいてより高度な耐クラッシュ性を提供するレプリケーションを設定できます。MariaDB DB インスタンスの GTIDs を使用してレプリケーションを設定する方法の詳細については、「Amazon RDS MariaDB DB インスタンスへの GTID ベースレプリケーションの設定」を参照してください。

1 つの DB インスタンスから最大 5 つのリードレプリカを作成できます。レプリケーションを効率的に実行するには、各リードレプリカに、ソース DB インスタンスと同程度の計算およびストレージリソースが必要です。ソース DB インスタンスを拡張した場合、リードレプリカも拡張する必要があります。

リードレプリカがいずれかのバージョンの MariaDB または MySQL 5.6 以降を実行している場合、別のリードレプリカのソース DB インスタンスとして指定できます。たとえば、MyDBInstance から ReadReplica1 を作成した後、ReadReplica1 から ReadReplica2 を作成できます。MyDBInstance に加えられた更新は ReadReplica1 にレプリケートされた後、ReadReplica1 から ReadReplica2 にレプリケートされます。レプリケーションチェーンにインスタンスを 4 つ以上作成することはできません。たとえば、MySourceDBInstance から ReadReplica1 を作成した後、ReadReplica1 から ReadReplica2 を作成し、ReadReplica2 から ReadReplica3 を作成できますが、ReadReplica3 から ReadReplica4 を作成することはできません。

Amazon RDS MariaDB または MySQL バージョン 5.6 以降のリードレプリカで自動バックアップを有効にするには、まずリードレプリカを作成し、リードレプリカを変更して自動バックアップを有効にします。

リードレプリカは読み取りクエリをサポートするように設計されていますが、ときどき更新が必要になることがあります。たとえば、インデックスを追加して、レプリカにアクセスする特定のタイプのクエリを高速化する必要が生じることがあります。更新を有効にするには、リードレプリカの DB パラメータグループで read_only パラメータを 0 に設定します。

ソースインスタンスのリードレプリカが 5 個の制限を超えない限り、同じソース DB インスタンスを参照するリードレプリカ作成または削除アクションを複数同時に実行できます。

リードレプリカは、シングル AZ DB インスタンス配置からもマルチ AZ DB インスタンスは一からも作成できます。重要なシステムの耐久性と可用性を高めるにはマルチ AZ 配置を使用しますが、読み取り専用クエリを処理するためにマルチ AZ セカンダリを使用することはできません。トラフィックの多いマルチ AZ DB インスタンスからリードレプリカを作成して、ソース DB インスタンスから読み取りクエリをオフロードする必要があります。マルチ AZ 配置のソースインスタンスがセカンダリにフェイルオーバーされた場合、レプリケーションソースとしてセカンダリを使用するように関連するリードレプリカが切り替えられます。

MySQL および MariaDB DB では、障害中に binlog イベントがフラッシュされない場合、状況によってはリードレプリカをセカンダリに切り替えることができない場合があります。この場合、リードレプリカを手動で削除して作成し直す必要があります。MySQL 5.5 では、sync_binlog=1 および innodb_support_xa=1 動的変数を設定することで、この可能性を下げることができます。これらの設定によりパフォーマンスが低下することがあるため、本稼働環境に変更を実装する前に影響をテストしてください。これらの問題は、MySQL 5.6 以降または MariaDB を使用すると発生しにくくなります。MySQL 5.6 以降または MariaDB が動作するインスタンスの場合、パラメータはデフォルトで sync_binlog=1 および innodb_support_xa=1 に設定されます。

通常は、Amazon RDS DB インスタンス間にレプリケーションを設定しますが、Amazon RDS の外部で実行されている MySQL または MariaDB のインスタンスからデータベースをインポートしたり、それらのインスタンスにデータベースをエクスポートしたりするようにレプリケーションを設定できます。詳細については、「わずかなダウンタイムでの Amazon RDS MySQL または MariaDB DB インスタンスへのデータのインポート」および「レプリケーションを使用した MySQL データのエクスポート」を参照してください。

システムのストアドプロシージャ mysql.rds_stop_replication および mysql.rds_start_replication を呼び出すことにより、Amazon RDS DB インスタンスでレプリケーションプロセスを停止して再開始することができます。これは、大きいインデックスの作成など、長時間実行されている操作の 2 つの Amazon RDS インスタンス間でレプリケーションするときに実行できます。レプリケーションは、データベースをインポートまたはエクスポートするときに停止して開始する必要もあります。詳細については、「わずかなダウンタイムでの Amazon RDS MySQL または MariaDB DB インスタンスへのデータのインポート」および「レプリケーションを使用した MySQL データのエクスポート」を参照してください。

DB インスタンスを削除する同じメカニズムを使用して、リードレプリカを明示的に削除する必要があります。レプリカを削除しないでソース DB インスタンスを削除した場合、各レプリカはスタンドアロンのシングル AZ DB インスタンスに昇格されます。

他のリードレプリカに順番にレプリケーションを行う MySQL または MariaDB リードレプリカを昇格させた場合、そのレプリケーションはアクティブなままです。MyDBInstance1 が MyDBInstance2 にレプリケーションされ、MyDBInstance2 が MyDBInstance3 にレプリケーションされる例について考えてみましょう。MyDBInstance2 を昇格させた場合、MyDBInstance1 から MyDBInstance2 へのレプリケーションは行われなくなりますが、MyDBInstance2 は引き続き MyDBInstance3 にレプリケーションされます。

レプリケーションが、手動またはレプリケーションエラーにより、30 日より長く連続して停止していた場合、マスター DB インスタンスに関するストレージ要件の増加と長いフェイルオーバー時間を回避するために、Amazon RDS はマスター DB インスタンスとすべてのリードレプリカとの間のレプリケーションを終了します。レプリケーションの終了後もリードレプリカ DB インスタンスは使用できますが、リードレプリカに必要なバイナリログはマスター DB インスタンスから削除されるため、レプリケーションを再開することはできません。レプリケーションを再開するには、マスター DB インスタンスの新しいリードレプリカを作成する必要があります。

リードレプリカの作成

AWS マネジメントコンソール、AWS CLI、または AWS API を使用して、既存の MySQL、MariaDB、または PostgreSQL DB インスタンスからリードレプリカを作成できます。リードレプリカは、レプリケーション元のソース DB インスタンスの DB インスタンス識別子である SourceDBInstanceIdentifier を指定することで作成できます。

リードレプリカの作成を開始すると、Amazon RDS は、ソース DB インスタンスの DB スナップショットを取得し、レプリケーションを開始します。その結果、DB スナップショットを撮る間、ソース DB インスタンスに軽度の入出力停止が発生します。I/O の一時停止は、通常約 1 分です。ソース DB インスタンスがマルチ AZ 配置の場合は、回避できます (マルチ AZ 配置の場合は、DB スナップショットがスタンバイから取得されます)。長時間実行されているアクティブなトランザクションがあると、リードレプリカの作成プロセス速度が低下するため、長時間実行されているトランザクションが完了してからリードレプリカを作成してください。同じソース DB インスタンスから複数のリードレプリカを同時に作成する場合、Amazon RDS は初回の作成アクションの開始時にスナップショットを 1 つだけ取得します。

リードレプリカを作成するときは、いくつかの考慮事項があります。最初に、バックアップ保持期間を 0 以外の値に設定することで、ソース DB インスタンスで自動バックアップを有効にする必要があります。この要件は、別のリードレプリカのソース DB インスタンスであるリードレプリカにも適用されます。MySQL DB インスタンスでは、自動バックアップは、MySQL 5.6 以降 (MySQL バージョン 5.5 は対象外) を実行しているリードレプリカでのみサポートされます。Amazon RDS MySQL バージョン 5.6 以降のリードレプリカで自動バックアップを有効にするには、まずリードレプリカを作成し、リードレプリカを変更して自動バックアップを有効にします。

MyISAM を使用する MySQL DB インスタンスを準備する

MySQL DB インスタンスで MyISAM などの非処理エンジンを使う場合は、以下の手順に従ってリードレプリカを設定する必要があります。このステップは、リードレプリカとお客様のデータとの整合性を保つために必要です。すべてのテーブルが InnoDB などのトランザクションエンジンを使用している場合には、このステップは必要ありません。

  1. ソース DB インスタンスの非トランザクションテーブルのすべてのデータ操作言語 (DML) とデータ定義言語 (DDL) の操作を停止します。SELECT 記述で実行を続けます。

  2. ソース DB インスタンスでテーブルをフラッシュおよびロックします。

  3. 以下のセクションのいずれかの方法を使用してリードレプリカを作成します。

  4. DescribeDBInstances API 操作などを使用して、リードレプリカ作成の進行状況を確認します。リードレプリカが使用可能になったら、ソース DB インスタンスのテーブルのロックを解除し、通常のデータベース操作を再開します。

AWS マネジメントコンソール

To create a Read Replica from a source MySQL, MariaDB, or PostgreSQL DB instance

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

  2. In the navigation pane, choose DB Instances.

  3. In the Instances pane, choose the MySQL, MariaDB, or PostgreSQL DB instance that you want to use as the source for a Read Replica and choose Create Read Replica from Instance Actions.

  4. Choose the instance specifications you want to use. It is a best practice to use the same DB instance class and storage type for the Read Replica.

  5. Choose the settings you want to use. For DB Instance Identifier, type a name for the Read Replica. Adjust other settings as needed.

  6. Choose the network, security, database, and maintenance settings you want to use.

  7. Choose Create Read Replica.

CLI

ソース MySQL、MariaDB、または PostgreSQL DB インスタンスからリードレプリカを作成するには、AWS CLI の create-db-instance-read-replica コマンドを使用します。

Linux、OS X、Unix の場合:

Copy
aws rds create-db-instance-read-replica \ --db-instance-identifier myreadreplica \ --source-db-instance-identifier mydbinstance

Windows の場合:

Copy
aws rds create-db-instance-read-replica ^ --db-instance-identifier myreadreplica ^ --source-db-instance-identifier mydbinstance

API

異なる AWS リージョンでソースの MySQL、MariaDB、または PostgreSQL DB インスタンスからリードレプリカを作成するには、、Amazon RDS API 組み込み関数 CreateDBInstanceReadReplica を呼び出します。

Copy
https://rds.amazonaws.com/ ?Action=CreateDBInstanceReadReplica &DBInstanceIdentifier=myreadreplica &SourceDBInstanceIdentifier=mydbinstance &Version=2012-01-15 &SignatureVersion=2 &SignatureMethod=HmacSHA256 &Timestamp=2012-01-20T22%3A06%3A23.624Z &AWSAccessKeyId=<AWS Access Key ID> &Signature=<Signature>

DB インスタンスとなるようにリードレプリカを昇格

スタンドアロンのシングル AZ DB インスタンスに MySQL、MariaDB、または PostgreSQL リードレプリカを昇格させることができます。リードレプリカを昇格させると、使用可能になる前に DB インスタンスが再起動されます。

リードレプリカをシングル AZ DB インスタンスに変換する理由はいくつかあります。

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

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

  • 災害対策の実装 – ソース DB インスタンスで障害が発生した場合は、データ復旧スキームとしてリードレプリカを使用できます。ただし、ユースケースで同期レプリケーション、自動障害検出、フェイルオーバーが求められる場合、代わりに DB インスタンスをマルチ AZ 配置として実行することをお勧めします。非同期レプリケーションの悪影響や限界に気付いたが、それでもデータ復旧にリードレプリカの昇格を使用したい場合、まずリードレプリカを作成してから、ソース DB インスタンスで障害をモニタリングします。障害が発生した場合、以下の作業を行います。

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

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

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

    これらのすべての操作は、Amazon Relational Database Service API Reference を使用して実行でき、Amazon Simple Workflow Service 開発者ガイド を使用することでプロセスを自動化できます。

リードレプリカを昇格させたときに作成された新しい DB インスタンスでは、前のリードレプリカソースのバックアップ保持期間、バックアップウィンドウ期間、およびパラメータグループが保持されます。リードレプリカのサイズによっては、昇格プロセスが完了するまで数分以上かかる場合があります。リードレプリカをシングル AZ DB インスタンスに昇格させたら、他のシングル AZ DB インスタンスと同様になります。たとえば、新しい DB インスタンスをマルチ AZ DB インスタンスに変換し、そこからリードレプリカを作成できます。DB スナップショットを取得し、ポイントインタイムリカバリ操作を実行することもできます。昇格された DB インスタンスはリードレプリカではなくなったため、レプリケーションターゲットとしては使用できません。ソース DB インスタンスに複数のリードレプリカがある場合、いずれかのリードレプリカを DB インスタンスに昇格させても、他のレプリカには影響が及びません。

リードレプリカを昇格させる前に、リードレプリカの自動バックアップを無効にすることをお勧めします。このアプローチにより、昇格プロセス中にバックアップは行われなくなります。インスタンスがプライマリインスタンスに昇格された場合、バックアップはバックアップ設定に基づいて行われます。

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

  1. リードレプリカソース DB インスタンスへのトランザクションの書き込みを停止し、すべての更新がリードレプリカに加えられるまで待ちます。データベース更新は、ソース DB インスタンスで行われた後にリードレプリカで行われるため、このレプリケーションは大幅に遅延する場合があります。「レプリカラグ」メトリックを使用して、リードレプリカにすべての更新がいつ加えられたかを確認できます。

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

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

    注記

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

AWS マネジメントコンソール

To promote a Read Replica to a DB instance

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

  2. In the Amazon RDS console, choose Read Replicas.

  3. In the Read Replicas pane, select the check box beside the Read Replica that you want to promote.

  4. Choose Promote Read Replica.

  5. In the Promote Read Replica dialog box, enter the backup retention period and the backup window for the new promoted DB instance.

  6. When the settings are as you want them, choose Continue.

  7. On the acknowledgment page, choose Yes, Promote.

CLI

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

Linux、OS X、Unix の場合:

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

Windows の場合:

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

API

リードレプリカを DB インスタンスに昇格させるには、PromoteReadReplica を呼び出します。

Copy
https://rds.amazonaws.com/ ?Action=PromoteReadReplica &DBInstanceIdentifier=myreadreplica &Version=2012-01-15 &SignatureVersion=2 &SignatureMethod=HmacSHA256 &Timestamp=2012-01-20T22%3A06%3A23.624Z &AWSAccessKeyId=<AWS Access Key ID> &Signature=<Signature>

リージョン間でリードレプリカをレプリケート

Amazon Relational Database Service (Amazon RDS) を使用すると、MySQL、PostgreSQL、または MariaDB リードレプリカをソース DB インスタンスとは異なる AWS リージョンに作成できます。リードレプリカを作成して、次を行います。

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

  • ユーザーに近いリージョンへの読み取り操作をスケールします。

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

ソースインスタンスとは異なるリージョンで MySQL、PostgreSQL、または MariaDB リードレプリカを作成する作業は、同じリージョンでレプリカを作成する作業と非常に似ています。複数のリージョンにわたるリードレプリカを作成するには、AWS マネジメントコンソール を使用するか、[create-db-instance-read-replica] コマンドを実行するか、または [CreateDBInstanceReadReplica] API アクションを呼び出すことができます。

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

注記

別のリージョンに Amazon Aurora DB クラスターのレプリカを作成することもできます。詳細については、「AWS リージョン間での Amazon Aurora DB クラスターのレプリケート」を参照してください。

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

AWS マネジメントコンソール

AWS マネジメントコンソール を使用して、複数のリージョンにわたるリードレプリカを作成できます。

To create a Read Replica across regions with the console

  1. Sign in to the AWS マネジメントコンソール and open the Amazon RDS console at https://console.aws.amazon.com/rds/.

  2. In the navigation pane, choose DB Instances.

  3. In the Instances window, choose the MySQL, MariaDB, or PostgreSQL DB instance that you want to use as the source for a Read Replica, and then choose Create Read Replica from Instance Actions. To create an encrypted Read Replica, the source DB instance must be encrypted. To learn more about encrypting the source DB instance, see Amazon RDS リソースの暗号化.

  4. Choose the instance specifications you want to use. We recommend that you use the same DB instance class and storage type for the Read Replica.

  5. Choose the other settings you want to use:

    • For DB Instance Identifier, type a name for the Read Replica.

    • In the Network & Security section, choose a value for Designation Region and Designation DB Subnet Group.

    • To create an encrypted Read Replica in another region, choose Enable Encryption, and then choose Master Key. For Master Key, choose the KMS key identifier of the destination region.

    • Choose the remaining network, security, database, and maintenance settings you want to use.

  6. Choose Create Read Replica.

AWS CLI

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

たとえば、ソース DB インスタンスが 米国東部(バージニア北部) リージョンにある場合、ARN は以下のような内容です。

arn:aws:rds:us-east-1:123456789012:db:my-mysql-instance

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

ソース DB インスタンスとは異なる AWS リージョンに暗号化されたリードレプリカを作成するには、目的のリージョンで AWS CLI コマンド create-db-instance-read-replica を使用します。別の AWS リージョンに暗号化されたリードレプリカを作成するには、次のパラメータを使用します。

  • --source-region – 暗号化されたリードレプリカを作成する AWS リージョン。source-region を指定しない場合、pre-signed-url の値を指定する必要があります。pre-signed-url は、リードレプリカの作成元のリージョンで呼び出す CreateDBInstanceReadReplica アクションに対する、署名バージョン 4 で署名されたリクエストを含む URL です。pre-signed-url の詳細については、「 CreateDBInstanceReadReplica」を参照してください。

  • --source-db-instance-identifier – 作成済みの暗号化されたリードレプリカの DB インスタンス識別子。この識別子は、コピー元リージョンの ARN 形式である必要があります。source-db-instance-identifier で指定したリージョンは、source-region として指定したリージョンと一致している必要があります。

  • --db-instance-identifier – 目的のリージョン内の暗号化されたリードレプリカの識別子。

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

次のコードでは、us-west-2 リージョンにリードレプリカが作成されます。

Linux、OS X、Unix の場合:

Copy
aws rds create-db-instance-read-replica \ --db-instance-identifier DBInstanceIdentifier \ --region us-west-2 \ --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:my-mysql-instance

Windows の場合:

Copy
aws rds create-db-instance-read-replica ^ --db-instance-identifier DBInstanceIdentifier ^ --region us-west-2 ^ --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:my-mysql-instance

次のコードでは、ソース DB インスタンスとは異なる AWS リージョンにリードレプリカが作成されます。create-db-instance-read-replica コマンドを呼び出すリージョンは、暗号化されたリードレプリカの保存先リージョンです。

Linux、OS X、Unix の場合:

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

Windows の場合:

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

API

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

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

たとえば、ソース DB インスタンスが 米国東部(バージニア北部) リージョンにある場合、ARN は以下のような内容です。

arn:aws:rds:us-east-1:123456789012:db:my-mysql-instance

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

Copy
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%253D CreateDBInstanceReadReplica %2526DestinationRegion%253Dus-east-1 %2526KmsKeyId%253Dmy-us-east-1-key %2526SourceDBInstanceIdentifier%253Darn%25253Aaws%25253Ards%25253Aus-west-2%1234567890 12%25253Adb%25253Amy-mysql-instance %2526SignatureMethod%253DHmacSHA256 %2526SignatureVersion%253D4%2526SourceDBInstanceIdentifier%253Darn%25253Aaws%25253Ards%25253Aus-west-2%25253A123456789012%25253Ainstance%25253Amysql-instance1-instance-20161115 %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=arn:aws:rds:us-west-2:123456789012:db:my-mysql-instance &Version=2012-01-15 &SignatureVersion=2 &SignatureMethod=HmacSHA256 &Timestamp=2012-01-20T22%3A06%3A23.624Z &AWSAccessKeyId=<AWS Access Key ID> &Signature=<Signature>

クロスリージョンレプリケーションの考慮事項

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

  • MariaDB、PostgreSQL (バージョン 9.4.7 および 9.5.2 を除く)、または MySQL 5.6 以降の Amazon RDS DB インスタンスを使用している場合は、リージョン間でのレプリケーションのみが可能です。

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

  • 別の Amazon RDS DB インスタンスのリードレプリカでないソース Amazon RDS DB インスタンスからのみ、クロスリージョン Amazon RDS リードレプリカを作成できます。

  • AWS GovCloud (US) リージョンとの間にレプリケーションチャネルをセットアップすることはできません。

  • ソースインスタンスにあるリードレプリカよりも、異なるリージョンにあるリードレプリカの方が、リージョンのデータセンター間のネットワークチャネルが長くなるため、ある程度遅延時間が長くなります。

  • リージョン内では、同じソース DB インスタンスから作成されたすべてのクロスリージョンリードレプリカが、同じ Amazon VPC 内または VPC の外部に存在する必要があります。クロスリージョンリードレプリカでは、--db-subnet-group-name パラメータを指定する Create Read Replica コマンドのいずれかで、同じ VPC の DB サブネットグループを指定する必要があります。

  • VPC にないソース DB インスタンスから、VPC にあるクロスリージョンリードレプリカを作成できます。VPC にあるソース DB インスタンスから、VPC にないクロスリージョンリードレプリカを作成することもできます。

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

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

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

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

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

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

MySQL および MariaDB インスタンスの場合、作成するクロスリージョンリードレプリカの数を減らすことで、データ転送コストを削減できます。たとえば、あるリージョンにソース DB インスタンスがあり、別のリージョンに 3 つのリードレプリカを作成する場合、ソース DB インスタンスからリードレプリカを 1 つだけ作成した後、ソース DB インスタンスではなく 1 つ目のリードレプリカから他の 2 つのレプリカを作成します。例として、あるリージョンに source-instance-1 がある場合は、次のようにできます。

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

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

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

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

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

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

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

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

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

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

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

    MySQL、MariaDB、および PostgreSQL リードレプリカの場合、Amazon RDS の ReplicaLag メトリクスを表示することで、Amazon CloudWatch でのレプリケーション遅延をモニタリングできます。MySQL と MariaDB の場合、ReplicaLag メトリクスでは、SHOW SLAVE STATUS コマンドの Seconds_Behind_Master フィールドの値がレポートされます。PostgreSQL の場合、ReplicaLag メトリクスでは SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS slave_lag の値がレポートされます。

    MySQL と MariaDB のレプリケーション遅延の一般的な原因は以下のとおりです。

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

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

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

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

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

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

例 VPC 外部でのクロスリージョンリードレプリカの作成

以下に示しているのは、us-east-1 にあるソース DB インスタンスから us-west-2 にリードレプリカを作成する例です。リードレプリカは、VPC の外部に作成されます。

Linux、OS X、Unix の場合:

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

Windows の場合:

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

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

これは、us-east-1 にあるソース DB インスタンスから us-west-2 にリードレプリカを作成する例です。リードレプリカは、指定された DB サブネットグループに関連付けられた VPC で作成されます。

Linux、OS X、Unix の場合:

Copy
aws rds create-db-instance-read-replica \ --db-instance-identifier SimCoProd01Replica01 \ --region us-west-2 --db-subnet-group-name my-us-west-2-subnet --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:SimcoProd01

Windows の場合:

Copy
aws rds create-db-instance-read-replica ^ --db-instance-identifier SimCoProd01Replica01 ^ --region us-west-2 --db-subnet-group-name my-us-west-2-subnet --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:SimcoProd01

読み込みレプリケーションのモニタリング

リードレプリカのステータスは、さまざまな方法でモニタリングできます。Amazon RDS コンソールには、リードレプリカのステータスが表示されます。リードレプリカのステータスは、AWS CLI の describe-db-instances コマンド、または Amazon RDS API の DescribeDBInstances アクションを使用して確認することもできます。

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

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

  • [Replicating]—リードレプリカが正常にレプリケーションされています。

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

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

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

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

MySQL または MariaDB Show Slave Status コマンドにより返される Seconds_Behind_Master データか、CloudWatchの「レプリカラグ」統計を確認することで、MySQL または MariaDB リードレプリカがソース DB インスタンスよりどの程度遅れているかをモニタリングできます。レプリカが環境よりかなり遅れている場合、リードレプリカを削除して作成し直すことを検討してください。さらに、リードレプリカのスケールを拡張してレプリケーションを高速化することも検討してください。

MySQL または MariaDB リードレプリカに関する問題のトラブルシューティング

MySQL および MariaDB のレプリケーションテクノロジーは非同期です。非同期的であるため、ソース DB インスタンスの BinLogDiskUsage やリードレプリカの ReplicaLag がときどき増加することがあります。たとえば、ソース DB インスタンスには大量の書き込みオペレーションが並行して行われますが、リードレプリカへの書き込みオペレーションは単一の I/O スレッドを使用してシリアル化されます。このため、ソースインスタンスとリードレプリカの間に遅延が生じる可能性があります。読み取り専用レプリカの詳細については、MySQL ドキュメントの『レプリケーション実装ガイド』を参照してください。MariaDB ドキュメントの読み取り専用のレプリカについては、「レプリケーションの概要」を参照してください。

ソース DB インスタンスに対する更新とリードレプリカに対するその後の更新の間の遅延を減らすには、次のいくつかの方法を行うことができます。

  • ストレージサイズと DB インスタンスクラスがソース DB インスタンスと同程度となるようにリードレプリカのサイズを決定します。

  • ソース DB インスタンスとリードレプリカにより使用される DB パラメータグループのパラメータ設定に互換性を確保します。詳細と例については、このセクションの後方にある max_allowed_packet パラメータの説明を参照してください。

Amazon RDS はリードレプリカのレプリケーションステータスをモニタリングし、リードレプリカで実行されている DML クエリが、ソース DB インスタンスに加えられた更新と競合するなど、何らかの理由でレプリケーションが停止した場合、リードレプリカインスタンスの Replication State フィールドを Error に更新します。[Replication Error] フィールドを参照することで、MySQL または MariaDB エンジンによりスローされた関連するエラーの詳細を確認できます。リードレプリカのステータスを示すイベントも生成されます (RDS-EVENT-0045RDS-EVENT-0046RDS-EVENT-0047 など)。イベントについてとイベントへのサブスクライブの詳細については、「Amazon RDS イベント通知の使用」を参照してください。MySQL エラーメッセージが返された場合、『MySQL のエラーメッセージドキュメント』でエラー番号を確認してください。MariaDB エラーメッセージが返された場合、『MariaDB のエラーメッセージドキュメント』でエラーを確認してください。

レプリケーションエラーを引き起こす一般的な問題は、リードレプリカの max_allowed_packet パラメータの値がソース DB インスタンスの max_allowed_packet パラメータより小さいことです。max_allowed_packet パラメータは、データベースで実行できる DML の最大サイズを指定するために使用される、DB パラメータグループで設定可能なカスタムパラメータです。ソース DB インスタンスに関連付けられている DB パラメータグループの max_allowed_packet パラメータ値が、ソースのリードレプリカに関連付けられた DB パラメータグループの max_allowed_packet パラメータ値より小さい場合、レプリケーションプロセスはエラー (Packet bigger than 'max_allowed_packet' bytes) をスローし、レプリケーションを停止することがあります。ソースとリードレプリカで同じ max_allowed_packet パラメータ値を持つ DB パラメータグループが使用されるように設定することにより、エラーを修正できます。

レプリケーションエラーを引き起こす可能性があります他の一般的な状況は次のとおりです。

  • リードレプリカのテーブルに書き込んでいる。リードレプリカでインデックスを作成する場合、read_only パラメータを 0 に設定してインデックスを作成する必要があります。リードレプリカのテーブルに書き込んだ場合、レプリケーションが中断する可能性があります。

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

  • SYSDATE() など、安全でない非決定的クエリを使用している。詳細については、「バイナリログ作成における安全なステートメントと安全でないステートメントの判断」を参照してください。

エラーを安全にスキップできると判断した場合、「現在のレプリケーションエラーのスキップ」セクションで説明されているステップに従うことができます。それ以外の場合は、リードレプリカを削除し、同じ DB インスタンス識別子を使用してインスタンスを作成することで、エンドポイントが以前のリードレプリカと同じままになるようにすることができます。レプリケーションエラーが解決すると、[Replication State] は [Replicating] に変化します。

PostgreSQL リードレプリカに関する問題のトラブルシューティング

PostgreSQL では、クロスリージョンレプリケーションにレプリケーションスロットを使用するため、同じリージョンとクロスリージョンのレプリケーションでは問題のトラブルシューティングプロセスが異なります。

リージョン内の PostgreSQL リードレプリカに関する問題のトラブルシューティング

データをリードレプリカに提供するために保持する先書きログ (WAL) ファイルの数は、PostgreSQL パラメータ、wal_keep_segments で指定します。 パラメータ値は、保持するログの数を指定します。パラメータ値の設定が低すぎると、リードレプリカでのストリーミングに大幅な遅延が発生し、レプリケーションが停止します。この場合、Amazon RDS によりレプリケーションエラーが報告され、ソース DB インスタンスのアーカイブされた WAL ログの再生によってリードレプリカで復旧が開始されます。この復旧プロセスは、レプリケーションのストリーミングを続行するのに十分なだけリードレプリカの遅延が解消されるまで続きます。

アーカイブされた WAL ファイルを再生すると、リードレプリカの PostgreSQL ログから、Amazon RDS でリードレプリカが復旧中であることが分かります。

Copy
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG:  switched WAL source from archive to stream after failure 2014-11-07 19:01:10 UTC::@:[11575]:LOG:  started streaming WAL from primary at 1A/D3000000 on timeline 1 2014-11-07 19:01:10 UTC::@:[11575]:FATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000010000001A000000D3 has already been removed 2014-11-07 19:01:10 UTC::@:[23180]:DEBUG:  could not restore file "00000002.history" from archive: return code 0 2014-11-07 19:01:15 UTC::@:[23180]:DEBUG:  switched WAL source from stream to archive after failure recovering 000000010000001A000000D3 2014-11-07 19:01:16 UTC::@:[23180]:LOG:  restored log file "000000010000001A000000D3" from archive

Amazon RDS で、リードレプリカの遅延が解消されストリーミングが再開されるのに十分なレプリカ上のアーカイブ WAL ファイルが再生されると、PostgreSQL はストリーミングを再開し、同じ行をログファイルに次のように書き込みます。

Copy
2014-11-07 19:41:36 UTC::@:[24714]:LOG:  started streaming WAL from primary at 1B/B6000000 on timeline 1

保持する WAL ファイルの数を決めるには、ログ内のチェックポイント情報を確認します。PostgreSQL ログの各チェックポイントに次の情報が示されます。これらログステートメントの "# recycled" トランザクションログファイルを確認することで、時間範囲内にリサイクルされるトランザクションファイルの数を把握し、またこの情報を使用して wal_keep_segments パラメータを調整できます。

Copy
2014-11-07 19:59:35 UTC::@:[26820]:LOG:  checkpoint complete: wrote 376 buffers (0.2%); 0 transaction log file(s) added, 0 removed, 1 recycled; write=35.681 s, sync=0.013 s, total=35.703 s; sync files=10, longest=0.013 s, average=0.001 s

たとえば、PostgreSQL ログの "checkpoint completed" ログステートメントで、5 分間に 35 個のファイルがリサイクルされたことが示された場合は、この使用パターンでは、リードレプリカは 5 分間に 35 のトランザクションファイルを処理し、ソース DB インスタンスがデフォルトの wal_keep_segments パラメータ値である 32 に設定された場合、非ストリーミング状態でリードレプリカが 5 分もたないことがわかります。

リージョン間の PostgreSQL リードレプリカに関する問題のトラブルシューティング

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

DB インスタンス上のワークロードにより大量の WAL データが発生する場合は、ソース DB インスタンスとリードレプリカの DB インスタンスクラスを、レプリカ用に 10 Gb という高いネットワークパフォーマンスのクラスに変更する必要があります。Amazon CloudWatch メトリクス Transaction Logs Generation は、ワークロードによる WAL データの生成率を把握するのに役立ちます。

クロスリージョンリードレプリカの状態を調べるには、以下の例のように、ソースインスタンス上の pg_replication_slots を照会できます。

Copy
postgres=# select * from pg_replication_slots; slot_name | plugin | slot_type | datoid | database | active | active_pid | xmin | catalog_xmin | restart_lsn _______________________________________________________________________________________________________________________________________________ rds_us_east_1_db_uzwlholddgpblksce6hgw4nkte | | physical | | | t | 12598 | | | 4E/95000060 (1 row)