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

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

Aurora レプリカ表示の使用

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

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

重要

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

Amazon Aurora MySQL のレプリケーションオプション

次のいずれのオプションの間でもレプリケーションを設定できます。

注記

また、Amazon Aurora DB クラスターのプライマリインスタンスを再起動すると、DB クラスター全体の一貫した読み取り/書き込みを保証するエントリポイントを再確立するために、DB クラスターの Aurora レプリカを自動的に再起動します。

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

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

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

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