Amazon Aurora
Aurora のユーザーガイド

Amazon Aurora MySQL を使用したシングルマスターレプリケーション

Aurora MySQL レプリケーション機能は、クラスターの高可用性とパフォーマンスの鍵となります。Aurora は、最大 15 個の Aurora レプリカを使用して簡単にクラスターの作成またはサイズ変更を行うことができます。

すべてのレプリカは同じ基盤となるデータから機能します。一部のデータベースインスタンスがオフラインになると、他のデータベースインスタンスはクエリの処理を続行したり、必要に応じて書き込みとして引き継ぐことができます。Aurora は複数のデータベースインスタンスに読取り専用接続を自動的に分散させ、Aurora クラスターがクエリ集約型のワークロードをサポートできるようにします。

以下は、Aurora MySQL レプリケーションのしくみと、レプリケーション設定を最大限の可用性とパフォーマンスを得るために調整する方法について説明しています。

注記

次に、シングルマスターレプリケーションを使用した Aurora クラスターのレプリケーション機能について説明します。この種類のクラスターは、Aurora のデフォルトです。Aurora マルチマスタークラスターについては、Aurora マルチマスタークラスターを使用する を参照してください。

Aurora レプリカ表示の使用

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

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

Aurora MySQL では、Aurora レプリカが削除されるとそのインスタンスエンドポイントはただちに削除され、Aurora レプリカも読み込みエンドポイントから削除されます。削除中の Aurora レプリカで実行されているステートメントがある場合は、削除までに 3 分の猶予期間があります。既存のステートメントは、猶予期間中に適切に終了する場合があります。猶予期間が終了すると、Aurora レプリカはシャットダウンし、削除されます。

重要

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

注記

プライマリインスタンスで実行された DDL ステートメントにより、関連付けられた Aurora レプリカのデータベース接続が中断される場合があります。Aurora レプリカ接続でテーブルなどのデータベースオブジェクトを使用中である場合、そのオブジェクトが DDL ステートメントを使用してプライマリインスタンスで変更されると、Aurora レプリカ接続は中断されます。

注記

中国 (寧夏) リージョンは、クロスリージョンリードレプリカをサポートしません。

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

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

注記

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

Amazon Aurora MySQL レプリケーションのパフォーマンスに関する考慮事項

Aurora MySQL 1.17.4 以降では、以下の機能を使用して、Aurora MySQL レプリケーションのパフォーマンスを微調整することができます。

レプリカログ圧縮機能は、レプリケーションメッセージのネットワーク帯域幅を自動的に縮小します。各メッセージはすべての Aurora レプリカに送信されるため、大規模なクラスターではメリットが大きくなります。この機能には、圧縮を実行する書き込みノードの CPU オーバーヘッドが含まれます。そのためこの機能は、CPU 容量が大きい 8xlarge および 16xlarge インスタンスクラスでのみ使用できます。これらのインスタンスクラスでは、デフォルトで有効になっています。aurora_enable_replica_log_compression パラメータをオフにして、この機能を制御できます。たとえば、書き込みノードが CPU 容量の最大に近い場合、大きなインスタンスクラスのレプリカログ圧縮をオフにすることができます。

バイナリログフィルタ処理機能は、レプリケーションメッセージのネットワーク帯域幅を自動的に縮小します。レプリケーションメッセージに含まれるバイナリログ情報は、Aurora レプリカで使用されないため、これらのノードに送信されるメッセージからは除外されます。この機能を制御するには、aurora_enable_repl_bin_log_filtering パラメータを変更します。このパラメータはデフォルトでオンになっています。この最適化は透過的であることを意図されているため、この設定をオフにできるのは、レプリケーションに関する問題の診断時またはトラブルシューティング時に限られる場合があります。この機能を使用できない古い Aurora MySQL クラスターなどの場合は、その動作に合わせてこの設定をオフにすることができます。

Amazon Aurora MySQL レプリケーションの高可用性に関する考慮事項

クラスター内に Aurora レプリカを増やすことで、可用性を確保することができます。一部のデータベースインスタンスが使用できなくなった場合でも、データの完全コピーを含むデータベースインスタンスは常に利用可能です。

複数の Aurora レプリカを使用することのデメリットは、基になるデータベースインスタンスが再起動されると、レプリカが短期間使用できなくなることです。これらの再起動は、メンテナンス操作、またはレプリカがマスターのあまりにも後ろに遅れすぎているときに発生する可能性があります。レプリカを再起動すると、対応するデータベースインスタンスへの既存の接続が中断されます。Aurora クラスターを再起動すると、すべてのレプリカが同時に使用できなくなります。

Aurora MySQL の 1.17.4 以降では、次の機能を使用すると、レプリカを再起動している間でも高い可用性を確保できます。

ダウンタイムのない再起動 (ZDR) 機能は、たとえばレプリカがマスターよりかなり遅れている場合などに、Aurora MySQL レプリカが再起動されたときの既存の接続を維持します。開いているトランザクションはすべてロールバックされ、アプリケーションはトランザクションを再試行する必要があります。この機能を有効にするには、クラスターのパラメータグループの aurora_enable_zdr パラメータをオンにします。このパラメータはデフォルトではオフになっています。

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