Amazon Aurora MySQL でのレプリケーション
Aurora MySQL レプリケーション機能は、クラスターの高可用性とパフォーマンスにとって重要な要素です。Aurora では、最大 15 個の Aurora レプリカを使用して、簡単にクラスターの作成またはサイズ変更を行うことができます。
すべてのレプリカは同じ基盤となるデータから機能します。一部のデータベースインスタンスがオフラインになると、他のデータベースインスタンスがクエリの処理を続行します。あるいは、必要に応じてライターの機能を引き継ぐことができます。Aurora は複数のデータベースインスタンスに読み取り専用接続を自動的に分散させ、Aurora クラスターがクエリ負荷の重いワークロードをサポートできるようにします。
以下のトピックでは、Aurora MySQL レプリケーションのしくみと、レプリケーション設定を最大限の可用性とパフォーマンスを得るために調整する方法について説明します。
トピック
- Aurora レプリカの使用
- Amazon Aurora MySQL のレプリケーションオプション
- Amazon Aurora MySQL レプリケーションのパフォーマンスに関する考慮事項
- ダウンタイムのない再起動 (ZDR) (Amazon Aurora MySQL 用)
- Aurora MySQL でのレプリケーションフィルターの設定
- Amazon Aurora MySQL レプリケーションのモニタリング
- Amazon Aurora MySQL DB クラスターでのローカル書き込み転送の使用
- AWS リージョン 間での Amazon Aurora MySQL DB クラスターのレプリケーション
- Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)
- Amazon Aurora MySQL の GTID ベースレプリケーションを使用する
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 のレプリケーションオプション
次のいずれのオプションの間でもレプリケーションを設定できます。
-
異なる AWS リージョン の 2 つの Aurora MySQL DB クラスター (Aurora MySQL DB クラスターのクロスリージョンリードレプリカを作成)。
詳細については、「AWS リージョン 間での Amazon Aurora MySQL DB クラスターのレプリケーション」を参照してください。
-
同一の AWS リージョン の 2 つの Aurora MySQL DB クラスター (MySQL バイナリログ (binlog) のレプリケーションを使用)。
詳細については、「Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)」を参照してください。
-
出典としての RDS for MySQL DB インスタンスと Aurora MySQL DB クラスター (RDS for MySQL DB インスタンスの Aurora リードレプリカを作成)。
このアプローチを使用すると、Aurora への移行中に既存および進行中のデータ変更を Aurora MySQL に取り込むことができます。詳細については、「Aurora リードレプリカを使用した、RDS for MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターへのデータの移行」を参照してください。
また、このアプローチを使用して、データの読み取りクエリのスケーラビリティを向上させることもできます。これを行うには、読み取り専用 Aurora MySQL クラスター内の複数の DB インスタンスを使用してデータをクエリします。詳細については、「Amazon Aurora を使用した MySQL データベースの読み取りスケーリング」を参照してください。
-
1 つの AWS リージョン 内の Aurora MySQL DB クラスターと、異なるリージョンにある最大 5 つの Aurora 読み取り専用 Aurora MySQL DB クラスター (Aurora Global Database を作成)。
Aurora Global Database を使用して、ワールドワイドなフットプリントを持つアプリケーションをサポートできます。プライマリ Aurora MySQL DB クラスターには、ライターインスタンスと最大 15 個の Aurora レプリカがあります。読み取り専用セカンダリ Aurora MySQL DB クラスターは、それぞれ最大 16 個の Aurora レプリカで構成できます。詳細については、「Amazon Aurora Global Database の使用」を参照してください。
注記
また、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 の場合、バイナリログフィルタリングは常に有効です。
ダウンタイムのない再起動 (ZDR) (Amazon Aurora MySQL 用)
ダウンタイムのない再起動 (ZDR) 機能は、特定の種類の再起動中に DB インスタンスへのアクティブな接続の一部または全部を保持できます。ZDR は、Aurora がエラー条件 (レプリカが出典より遅すぎるなど) を解決するために自動的に実行する再起動に適用されます。
重要
ZDR メカニズムはベストエフォートベースで動作します。ZDR が適用される場合を決定する Aurora MySQL バージョン、インスタンスクラス、エラー条件、互換性のある SQL オペレーション、およびその他の要因は、いつでも変更される可能性があります。
Aurora MySQL 2.x の ZDR にはバージョン 2.10 以降が必要です。ZDR は Aurora MySQL 3.x のすべてのマイナーバージョンで利用可能です。Aurora MySQL バージョン 2 と 3 では、ZDR メカニズムはデフォルトでオンになっており、Aurora は aurora_enable_zdr
パラメータを使用しません。
Aurora は、停止時間ゼロの再起動に関連するアクティビティに関するレポートを、 [イベント] ページに表示します。Aurora は、ZDR メカニズムを使用して再起動を試みる際にイベントを記録します。このイベントは、Aurora が再起動を実行する理由を示します。その後、Aurora は再起動の完了時に別のイベントを記録します。この最終イベントは、再起動中にプロセスに要した時間、および保持またはドロップされた接続の数を報告します。データベースエラーログを参照して、再起動中に発生した処理の詳細を確認できます。
ZDR オペレーションが成功した後も接続はそのまま残りますが、一部の可変と機能は再初期化されます。次の種類の情報は、ダウンタイムのない再起動によって生じる再起動を通じては保持されません。
-
グローバル可変 Aurora はセッション可変を復元しますが、再起動後のグローバル可変の復元は行いません。
-
ステータス可変。特に、エンジンのステータスによって報告される稼働時間の値はリセットされます。
-
LAST_INSERT_ID
. -
テーブルのメモリ内
auto_increment
状態。メモリ内自動インクリメント状態が再初期化されます。自動インクリメント値の詳細については、MySQL リファレンスマニュアルを参照してください。 -
INFORMATION_SCHEMA
およびPERFORMANCE_SCHEMA
テーブルからの診断情報。この診断情報は、SHOW PROFILE
やSHOW PROFILES
などのコマンドの出力にも表示されます。
次の表では、クラスター内の DB インスタンスを再起動するときに Aurora が ZDR メカニズムを使用できるかどうかを決定するバージョン、インスタンスロール、およびその他の状況を示しています。
Aurora MySQL バージョン | ZDR はライターに適用されますか? | ZDR はリーダーに適用されますか? | ZDR は常に有効ですか? | 注意 |
---|---|---|---|---|
2.x、2.10.0 未満 |
いいえ |
いいえ |
該当なし |
ZDR はこれらのバージョンでは利用できません。 |
2.10.0 ~ 2.11.0 |
はい |
はい |
はい |
Aurora は、アクティブな接続で進行中のトランザクションをロールバックします。アプリケーションはトランザクションを再試行する必要があります。 Aurora は、TLS/SSL、一時テーブル、テーブルロック、またはユーザーロックを使用するすべての接続をキャンセルします。 |
2.11.1 以降 |
はい |
はい |
はい |
Aurora は、アクティブな接続で進行中のトランザクションをロールバックします。アプリケーションはトランザクションを再試行する必要があります。 Aurora は、一時テーブル、テーブルロック、またはユーザーロックを使用するすべての接続をキャンセルします。 |
3.01 ~ 3.03 |
はい |
はい |
はい |
Aurora は、アクティブな接続で進行中のトランザクションをロールバックします。アプリケーションはトランザクションを再試行する必要があります。 Aurora は、TLS/SSL、一時テーブル、テーブルロック、またはユーザーロックを使用するすべての接続をキャンセルします。 |
3.04 以上 |
はい |
はい |
はい |
Aurora は、アクティブな接続で進行中のトランザクションをロールバックします。アプリケーションはトランザクションを再試行する必要があります。 Aurora は、一時テーブル、テーブルロック、またはユーザーロックを使用するすべての接続をキャンセルします。 |
Aurora MySQL でのレプリケーションフィルターの設定
レプリケーションフィルターを使用して、リードレプリカでレプリケートするデータベースとテーブルを指定できます。レプリケーションフィルターは、データベースとテーブルをレプリケーションに含めることも、レプリケーションから除外することもできます。
レプリケーションフィルターの使用例は以下のとおりです。
-
リードレプリカのサイズを縮小します。レプリケーションフィルタリングを使用すると、リードレプリカで必要のないデータベースとテーブルを除外できます。
-
セキュリティ上の理由から、データベースとテーブルをリードレプリカから除外するため。
-
異なるリードレプリカで、特定のユースケースごとにさまざまなデータベースとテーブルを複製するため。例えば、分析やシャーディングに特定のリードレプリカを使用できます。
-
異なる AWS リージョン にリードレプリカがある DB クラスターで、異なる AWS リージョン に異なるデータベースまたはテーブルを複製するには。
-
インバウンドレプリケーショントポロジでレプリカとして設定されている Aurora MySQL DB クラスターでレプリケートするデータベースとテーブルを指定するには。この設定の詳細については、「Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)」を参照してください。
トピック
Aurora MySQL のレプリケーションフィルターパラメータの設定
レプリケーションフィルターを設定するには、次のパラメータを設定します。
-
binlog-do-db
- 指定されたバイナリログテーブルに変更を複製します。バイナリログソースクラスターに対してこのパラメータを設定すると、パラメータで指定されたバイナリログのみが複製されます。 -
binlog-ignore-db
- 指定されたバイナリログテーブルに変更を複製しません。バイナリログソースクラスターに対してbinlog-do-db
パラメータが設定されている場合、このパラメータは評価されません。 -
replicate-do-db
- 指定したデータベースに変更を複製します。バイナリログソースクラスターに対してこのパラメータを設定すると、パラメータで指定されたデータベースのみが複製されます。 -
replicate-ignore-db
- 指定したデータベースに変更を複製しないでください。バイナリログレプリカスクラスターに対してreplicate-do-db
パラメータが設定されている場合、このパラメータは評価されません。 -
replicate-do-table
-指定されたテーブルに変更を複製します。このパラメータをリードレプリカに設定した場合、パラメータで指定したテーブルのみが複製されます。また、replicate-do-db
またはreplicate-ignore-db
パラメータが設定されている場合は、指定されたテーブルを含むデータベースを、必ずバイナリログレプリカクラスターのレプリケーションに含めます。 -
replicate-ignore-table
- 指定したテーブルに変更を複製しないでください。バイナリログレプリカスクラスターに対してreplicate-do-table
パラメータが設定されている場合、このパラメータは評価されません。 -
replicate-wild-do-table
- 指定したデータベースおよびテーブル名のパターンに基づいてテーブルを複製します。%
および_
ワイルドカードの文字がサポート対象となります。replicate-do-db
またはreplicate-ignore-db
パラメータが設定されている場合は、指定されたテーブルを含むデータベースを、必ずバイナリログレプリカクラスターのレプリケーションに含めます。 -
replicate-wild-ignore-table
- 指定したデータベースおよびテーブル名のパターンに基づいてテーブルを複製しないでください。%
および_
ワイルドカードの文字がサポート対象となります。バイナリログレプリカスクラスターに対してreplicate-do-table
またはreplicate-wild-do-table
パラメータが設定されている場合、このパラメータは評価されません。
パラメータは、記載されている順序に沿って評価されます。これらのパラメータの詳細な仕組みについては、MySQL のドキュメントを参照してください。
-
一般的な情報については、 Replica Server Options and Variables
を参照してください。 -
データベースレプリケーションのフィルターパラメータを評価する方法については、 Evaluation of Database-Level Replication and Binary Logging Options
を参照してください。 -
テーブルレプリケーションのフィルターパラメータを評価する方法については、Evaluation of Table-Level Replication Options
を参照してください。
デフォルトでは、これらの各パラメータの値は空です。各バイナリログクラスターで、これらのパラメータを使用してレプリケーションフィルターを設定、変更、削除することができます。これらのパラメータの 1 つを設定する場合は、各フィルターを他のフィルターとコンマで区切ります。
%
および _
パラメータで replicate-wild-do-table
および replicate-wild-ignore-table
ワイルドカードの文字を使用できます。%
ワイルドカードは任意の文字数と一致し、_
ワイルドカードは 1 文字のみと一致します。
ソース DB インスタンスのバイナリログ形式は、データ変更のレコードを決定するため、レプリケーションでは重要です。binlog_format
パラメータの設定により、レプリケーションが行ベースかステートメントベースかが決まります。詳細については、「Aurora MySQL バイナリログの設定」を参照してください。
注記
ソース DB インスタンスの binlog_format
設定に関係なく、すべてのデータ定義言語 (DDL) ステートメントはステートメントとして複製されます。
Aurora MySQL のレプリケーションフィルターの制限
Aurora MySQL のレプリケーションフィルターには、次の制限が適用されます。
-
レプリケーションフィルターは、Aurora MySQL バージョン 3 でのみサポートされます。
-
各レプリケーションフィルターのパラメータには、2,000 文字といった制限があります。
-
レプリケーションフィルターでは、カンマはサポートされていません。
-
レプリケーションフィルタリングは、XA トランザクションをサポートしていません。
詳細については、MySQL ドキュメントの「XA トランザクションの制限
」を参照してください。
Aurora MySQL のレプリケーションフィルターの例
リードレプリカのレプリケーションフィルタリングを設定するには、リードレプリカに関連付けられている DB クラスターパラメータグループのレプリケーションフィルタリングパラメータを変更します。
注記
デフォルトの DB クラスターパラメータグループを変更することはできません。リードレプリカがデフォルトのパラメータグループを使用している場合は、新しいパラメータグループを作成してリードレプリカに関連付けます。DB クラスターパラメータグループの詳細については、「「パラメータグループを使用する」 」を参照してください。
AWS Management Console、AWS CLI、または RDS API を使用して、DB クラスターパラメータグループのパラメータを設定できます。パラメータの設定の詳細については、「DB パラメータグループのパラメータの変更」を参照してください。DB クラスターパラメータグループのパラメータを設定すると、そのパラメータグループに関連付けられているすべての DB クラスターがパラメータ設定を使用します。DB クラスターパラメータグループでレプリケーションフィルタリングパラメータを設定する場合は、パラメータグループがリードレプリカクラスターにのみ関連付けられていることを確認してください。ソース DB インスタンスのレプリケーションフィルターのパラメータは空のままにします。
次の例では、AWS CLI を使用してパラメータを設定します。これらの例では、CLI コマンドが完了した直後にパラメータの変更が行われるように ApplyMethod
を immediate
に設定しています。リードレプリカの再起動後に保留中の変更を適用する場合は、ApplyMethod
を pending-reboot
に設定します。
以下の例では、レプリケーションフィルターを設定します。
例 レプリケーションにデータベースを含める
次の例では、レプリケーションに mydb1
データベースと mydb2
データベースが含まれています。
Linux、macOS、Unix の場合:
aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate"
Windows の場合:
aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate"
例 レプリケーションにテーブルを含める
次の例には、レプリケーションのデータベース table1
の table2
テーブルと mydb1
テーブルが含まれています。
Linux、macOS、Unix の場合:
aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate"
Windows の場合:
aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate"
例 ワイルドカードの文字を使用してレプリケーションにテーブルを含める
次の例には、レプリケーションのデータベース order
の return
および mydb
で始まる名前のテーブルが含まれています。
Linux、macOS、Unix の場合:
aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate"
Windows の場合:
aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate"
例 レプリケーションからデータベースを除外する
次の例では、mydb5
データベースと mydb6
データベースをレプリケーションから除外しています。
Linux、macOS、Unix の場合:
aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6',ApplyMethod=immediate"
Windows の場合:
aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6,ApplyMethod=immediate"
例 レプリケーションからテーブルを除外する
次の例では、データベース mydb5
のテーブル table1
とデータベース mydb6
の table2
をレプリケーションから除外しています。
Linux、macOS、Unix の場合:
aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate"
Windows の場合:
aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate"
例 ワイルドカードの文字を使用したレプリケーションからテーブルを除外する
次の例では、データベース order
の return
および mydb7
で始まる名前のテーブルをレプリケーションから除外しています。
Linux、macOS、Unix の場合:
aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate"
Windows の場合:
aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate"
リードレプリカのレプリケーションフィルターを表示する
リードレプリカのレプリケーションフィルターは、次の方法で表示できます。
-
リードレプリカに関連付けられているパラメータグループのレプリケーションフィルタリングパラメータの設定を確認してください。
手順については、「DB パラメータグループのパラメータ値を表示する」を参照してください。
-
MySQL クライアントで、リードレプリカに接続し、
SHOW REPLICA STATUS
ステートメントを実行します。出力の次のフィールドには、リードレプリカのレプリケーションフィルターが表示されます。
-
Binlog_Do_DB
-
Binlog_Ignore_DB
-
Replicate_Do_DB
-
Replicate_Ignore_DB
-
Replicate_Do_Table
-
Replicate_Ignore_Table
-
Replicate_Wild_Do_Table
-
Replicate_Wild_Ignore_Table
これらのフィールドの詳細については、MySQL のドキュメントの Checking Replication Status
を参照してください。 -
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 クラスターでのメトリクスのモニタリング」を参照してください。