Amazon Aurora MySQL でのレプリケーション - Amazon Aurora
Aurora レプリカレプリケーションオプションレプリケーションのパフォーマンス レプリケーションのモニタリング

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

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

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

以下のトピックでは、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 レプリカが削除されるとそのインスタンスエンドポイントは直ちに削除され、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 レプリケーションのパフォーマンスを微調整することができます。

レプリカログ圧縮機能は、レプリケーションメッセージのネットワーク帯域幅を自動的に縮小します。各メッセージはすべての Aurora レプリカに送信されるため、大規模なクラスターではメリットが大きくなります。この機能には、圧縮を実行する書き込みノードの CPU オーバーヘッドが含まれます。Aurora MySQL バージョン 2 とバージョン 3 では、常に有効になっています。

バイナリログフィルタ処理機能は、レプリケーションメッセージのネットワーク帯域幅を自動的に縮小します。レプリケーションメッセージに含まれるバイナリログ情報は、Aurora レプリカで使用されないため、これらのノードに送信されるメッセージからは除外されます。

Aurora MySQL バージョン 2 の場合、aurora_enable_repl_bin_log_filtering パラメーターを変更することにより、この機能を制御できます。このパラメータはデフォルトでオンになっています。この最適化は透過的であることを意図されているため、この設定をオフにできるのは、レプリケーションに関する問題の診断時またはトラブルシューティング時に限られる場合があります。この機能を使用できない古い Aurora MySQL クラスターなどの場合は、その動作に合わせてこの設定をオフにすることができます。

Aurora MySQL バージョン 3 の場合、バイナリログフィルタリングは常に有効です。

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

読み取りのスケーリングと高可用性は最短遅延時間に左右されます。Amazon CloudWatch AuroraReplicaLag メトリクスをモニタリングすることによって、Aurora レプリカが Aurora MySQL DB クラスターのプライマリインスタンスからどれくらい遅延しているかを確認できます。AuroraReplicaLag メトリクスは各 Aurora レプリカに記録されます。

プライマリ DB インスタンスは、AuroraReplicaLagMaximum メトリクスと AuroraReplicaLagMinimum Amazon CloudWatch メトリクスも記録します。AuroraReplicaLagMaximum メトリクスは、DB クラスターのプライマリ DB インスタンスと各 Aurora レプリカの間の最大遅延量を記録します。AuroraReplicaLagMinimum メトリクスは、DB クラスターのプライマリ DB インスタンスと各 Aurora レプリカの間の最小遅延量を記録します。

Aurora レプリカの遅延について最新の値が必要な場合は、Amazon CloudWatch で AuroraReplicaLag メトリクスを確認できます。Aurora レプリカの遅延は、information_schema.replica_host_status テーブル内にある Aurora MySQL DB クラスターの各 Aurora レプリカにも記録されます。このテーブルの詳細については、「information_schema.replica_host_status」を参照してください。

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