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

Amazon Aurora とのレプリケーション

Aurora レプリカは、Aurora DB クラスター内の独立したエンドポイントであり、読み取りオペレーションのスケーリングと可用性の向上のために最適です。最大 15 個の Aurora レプリカを、1 つのリージョンの中で DB クラスターが処理するアベイラビリティーゾーン全体に分散できます。DB クラスターボリュームは DB クラスターのデータの複数のコピーで構成されますが、クラスターボリューム内のデータは、DB クラスター内のプライマリインスタンスと Aurora レプリカに対する単一の論理ボリュームとして表されます。

この結果、すべての Aurora レプリカは、最短のレプリカラグでクエリの結果として同じデータを返します。レプリカラグは、通常はプライマリインスタンスが更新を書き込んだ後、100 ミリ秒未満です。レプリカラグは、データベースの変更レートによって異なります。つまり、データベースに対して大量の書き込みオペレーションが発生している間、レプリカラグが増加することがあります。

Aurora レプリカは、クラスターボリュームでの読み取りオペレーションに特化しているため、読み取りのスケーリングに最適です。書き込みオペレーションはプライマリインスタンスによって管理されます。クラスターボリュームは DB クラスター内のすべてのインスタンスで共有されるため、Aurora レプリカごとにデータのコピーをレプリケートする追加作業は必要ありません。対照的に、MySQL のリードレプリカは、単一スレッド上で、マスター DB インスタンスからローカルデータストアに対するすべての書き込みオペレーションを再生する必要があるため、大量の読み取りトラフィックをサポートする MySQL リードレプリカの能力に影響を与える可能性があります。

可用性を高めるために、フェイルオーバーターゲットとして Aurora レプリカを使用できます。つまり、プライマリインスタンスが失敗すると、Aurora レプリカがプライマリインスタンスに昇格します。ここでは、プライマリインスタンスに対して行われた読み取り要求と書き込み要求が失敗して例外が発生するときに、短時間の中断が発生するだけです。Aurora DB クラスターに Aurora レプリカが含まれていない場合は、障害イベント中にプライマリインスタンスが再作成されます。ただし、Aurora レプリカを昇格するほうが、プライマリインスタンスの再起動よりも大幅に短時間で行えます。可用性の高いシナリオでは、プライマリインスタンスと同じ DB インスタンスクラスの 1 つ以上の Aurora レプリカを、Aurora DB クラスターの複数のアベイラビリティーゾーン内に作成することをお勧めします。フェイルオーバーターゲットとしての Aurora レプリカについては、「Aurora DB クラスターの耐障害性」を参照してください。

重要

Aurora レプリカは常に、InnoDB テーブル上のオペレーションにデフォルトのトランザクション分離レベル REPEATABLE READ を使用します。SET TRANSACTION ISOLATION LEVEL コマンドは、Amazon Aurora DB クラスターのプライマリインスタンスのトランザクションレベルを変更する場合にのみ使用できます。この制限により、Aurora レプリカ上でのユーザーレベルのロックが回避され、Aurora レプリカで何千ものアクティブユーザーの接続のサポートをレプリカラグを最小限に抑えたまま拡大することができます。

Aurora レプリカを作成する方法については、「コンソールを使用した Aurora レプリカの作成」を参照してください。

異なる AWS リージョンにある 2 つの Amazon Aurora DB クラスター間でレプリケーションを設定できます。詳細については、「AWS リージョン間での Amazon Aurora DB クラスターのレプリケート」を参照してください。

MySQL バイナリログ (binlog) のレプリケーションを使用して、2 つの Amazon Aurora DB クラスター間のレプリケーションを設定できます。詳細については、「Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション」を参照してください。

マスターとして RDS MySQL DB インスタンスを MySQL DB インスタンスの Aurora リードレプリカを Aurora 作成することで DB クラスターの間のレプリケーションを自分で設定できます。通常、このアプローチは進行中のレプリケーションよりも、Aurora への移行時に使用されます。詳細については、「MySQL DB インスタンスから Amazon Aurora DB クラスターへのデータ移行 (リードレプリカを使用)」を参照してください。

注記

Amazon Aurora DB クラスターのプライマリインスタンスを再起動すると、その DB クラスターの Aurora レプリカも自動的に再起動されます。

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

読み取りのスケーリングと高可用性は最短遅延時間に左右されます。Amazon CloudWatch ReplicaLag メトリクスをモニタリングすることによって、Aurora レプリカで Aurora DB クラスターのプライマリインスタンスからどの程度の遅延が発生しているかをモニタリングできます。Aurora レプリカは、プライマリインスタンスと同じクラスターボリュームから読み取るため、ReplicaLag メトリクスは Aurora DB クラスターの場合とは異なる意味を持ちます。Aurora レプリカの ReplicaLag メトリクスは、プライマリインスタンスのページキャッシュと比較した場合の Aurora レプリカのページキャッシュの遅延を示します。

Aurora レプリカの遅延について最新の値が必要な場合は、Aurora DB クラスターの mysql.ro_replica_status テーブルをクエリし、Replica_lag_in_msec 列の値を確認します。この列の値は ReplicaLag メトリクスの値として Amazon CloudWatch に渡されます。mysql.ro_replica_status の値は、Aurora DB クラスターの INFORMATION_SCHEMA.REPLICA_HOST_STATUS テーブルでも提供されます。

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