Amazon Aurora MySQL でのレプリケーション - Amazon Aurora
Aurora レプリカレプリケーションオプションレプリケーションのパフォーマンスダウンタイムのない再起動 (ZDR)レプリケーションフィルターの設定 レプリケーションのモニタリング

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 の場合、バイナリログフィルタリングは常に有効です。

ダウンタイムのない再起動 (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 のドキュメントを参照してください。

デフォルトでは、これらの各パラメータの値は空です。各バイナリログクラスターで、これらのパラメータを使用してレプリケーションフィルターを設定、変更、削除することができます。これらのパラメータの 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 クラスターでのメトリクスのモニタリング」を参照してください。