Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション) - Amazon Aurora
MySQL または別の Aurora DB クラスターとのレプリケーションの設定レプリケーション出典とレプリケーションターゲット間でのパスワードの同期Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーションの停止Amazon Aurora を使用した MySQL データベースの読み取りスケーリングバイナリログのレプリケーションの最適化拡張バイナリログ記録の設定

Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)

Amazon Aurora MySQL は MySQL と互換性があるため、MySQL データベースと Amazon Aurora MySQL DB クラスターとの間のレプリケーションを設定できます。このタイプのレプリケーションでは、MySQL バイナリログレプリケーションが使用され、バイナリログレプリケーションとも呼ばれます。Aurora でバイナリログレプリケーションを使用する場合は、MySQL データベースで MySQL バージョン 5.5 以降を実行することをお勧めします。Aurora MySQL DB クラスターがレプリケーション出典またはレプリカである場合は、レプリケーションを設定できます。Amazon RDS MySQL DB インスタンス、Amazon RDS の外部の MySQL データベース、または別の Aurora MySQL DB クラスターを使用してレプリケートできます。

注記

特定のタイプの Aurora クラスター間では、バイナリログレプリケーションを使用できません。特に、バイナリログレプリケーションは、Aurora Serverless v1 クラスターでは使用できません。SHOW MASTER STATUS と SHOW SLAVE STATUS (Aurora MySQL バージョン 2)、 または SHOW REPLICA STATUS (Aurora MySQL バージョン 3) ステートメントが出力を返さない場合は、使用しているクラスターがバイナリログレプリケーションをサポートしていることを確認してください。

Aurora MySQL バージョン 3 では、バイナリログレプリケーションは、mysql システムデータベースに複製されません。Aurora MySQL バージョン 3 のバイナリログレプリケーションでは、パスワードとアカウントが複製されません。そのため、CREATE USER、GRANT、REVOKE などのデータ制御言語 (DCL) ステートメントは複製されません。

また、別の AWS リージョン で、RDS for MySQL DB インスタンスまたは Aurora MySQL DB クラスターに、レプリケートすることもできます。AWS リージョン 間のレプリケーションを実行する場合は、DB クラスターと DB インスタンスがパブリックにアクセス可能であることを確認してください。Aurora MySQL DB クラスターが VPC のプライベートサブネットにある場合は、AWS リージョン 間で VPC ピアリングを使用します。詳細については、「VPC 内の DB クラスターに別の VPC 内の EC2 インスタンスからアクセスする」を参照してください。

Aurora MySQL DB クラスターと別の AWS リージョン の Aurora MySQL DB クラスター間のレプリケーションを設定する場合、Aurora MySQL DB クラスターをソース DB クラスターとは別の AWS リージョン のリードレプリカとして作成できます。詳細については、「AWS リージョン 間での Amazon Aurora MySQL DB クラスターのレプリケーション」を参照してください。

Aurora MySQL 2 および 3 では、レプリケーションにグローバルトランザクション識別子 (GTID) を使用する外部のソースまたはターゲットと Aurora MySQL との間でレプリケートできます。Aurora MySQL DB クラスターの GTID 関連のパラメータ内に、外部データベースの GTID ステータスと互換性がある設定が含まれていることを確認してください。これを行う方法については、「Amazon Aurora MySQL の GTID ベースレプリケーションを使用する」を参照してください。Aurora MySQL バージョン 3.01 以降では、GTID を使用しない出典からレプリケートされたトランザクションに GTID を割り当てる方法を選択できます。その設定を制御するストアドプロシージャの詳細については、mysql.rds_assign_gtids_to_anonymous_transactions (Aurora MySQL バージョン 3) を参照してください。

警告

Aurora MySQL と MySQL との間で複製する場合は、必ず InnoDB テーブルのみを使用してください。MyISAM テーブルをレプリケートする場合は、これらのテーブルを以下のコマンドを使用して InnoDB に変換してから、レプリケーションを設定できます。

alter table <schema>.<table_name> engine=innodb, algorithm=copy;

MySQL または別の Aurora DB クラスターとのレプリケーションの設定

Aurora MySQL と MySQL との間でレプリケーションを設定するには、次のステップを使用します。各ステップについては、このトピックで詳しく説明します。

1. レプリケーション出典のバイナリログ記録を有効にする

2. レプリケーション出典のバイナリログを不要になるまで保持する

3. レプリケーションソースのスナップショットまたはダンプを作成する

4. レプリカターゲットにスナップショットまたはダンプをロードする

5. レプリケーションソースでレプリケーションユーザーを作成する

6. レプリカターゲットでレプリケーションを有効にする

7. レプリカをモニタリングする

1. レプリケーション出典のバイナリログ記録を有効にする

以下のデータベースエンジンのレプリケーション出典で、バイナリログを有効にする手順を確認します。

2. レプリケーション出典のバイナリログを不要になるまで保持する

MySQL バイナリログのレプリケーションを使用する場合、Amazon RDS はレプリケーションプロセスを管理しません。したがって、レプリケーション出典のバイナリログファイルは、変更がレプリカに適用されるまで保持する必要があります。このメンテナンスによって、障害発生時にソースデータベースを復元しやすくなります。

次のステップに従って、データベースエンジンのバイナリログを保持します。

3. レプリケーションソースのスナップショットまたはダンプを作成する

レプリケーションソースのスナップショットまたはダンプを使用して、データのベースラインコピーをレプリカにロードし、その時点からレプリケーションを開始します。

次のステップに従って、データベースエンジンのレプリケーションソースのスナップショットまたはダンプを作成します。

4. レプリカターゲットにスナップショットまたはダンプをロードする

Amazon RDS の外部 MySQL データベースのダンプからデータをロードする場合、ダンプファイルのコピー先となる EC2 インスタンスを作成してから、その EC2 インスタンスから DB クラスターまたは DB インスタンスにデータをロードします。この方法では、ダンプファイルを EC2 インスタンスにコピーする前に圧縮して、Amazon RDS へのデータのコピーに関連するネットワークコストを削減できます。また、ダンプファイルを暗号化して、ネットワーク経由で転送されるデータを保護することもできます。

次のステップに従って、レプリケーションソースのスナップショットまたはダンプをデータベースエンジンのレプリカターゲットにロードします。

5. レプリケーションソースでレプリケーションユーザーを作成する

レプリケーション専用のユーザー ID をソースに作成します。次に例を示します。

mysql> CREATE USER 'repl_user'@'<domain_name>' IDENTIFIED BY '<password>';

ユーザーには REPLICATION CLIENT および REPLICATION SLAVE 権限が必要です。ユーザーのこれらの権限を付与します。

暗号化レプリケーションを使用する必要がある場合は、レプリケーションのユーザーに対して SSL 接続を要求します。例えば、以下のいずれかのステートメントを使用して、ユーザーアカウント repl_user に SSL 接続を要求できます。

GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'<domain_name>';

GRANT USAGE ON *.* TO 'repl_user'@'<domain_name>' REQUIRE SSL;
注記

REQUIRE SSL が含まれていない場合には、レプリケーション接続がメッセージの表示なしで非暗号化接続に戻る場合があります。

6. レプリカターゲットでレプリケーションを有効にする

レプリケーションを有効化する前に、MySQL DB インスタンス レプリカターゲットのAurora MySQL DB クラスターまたは RDS のスナップショットを手動で作成することをお勧めします。問題が発生し、DB クラスターまたは DB インスタンスレプリカターゲットとのレプリケーションを再開する必要がある場合は、このスナップショットから DB クラスターまたは DB インスタンスを復元できます。そのために、再びレプリカターゲットにデータをインポートする必要はありません。

次のステップに従って、データベースエンジンでレプリケーションを有効にします。

レプリケーションが失敗した場合、レプリカにおいて意図しないI/Oが大幅に増加することで、パフォーマンスが低下する可能性があります。レプリケーションが失敗するか、不要になった場合は、mysql.rds_reset_external_master (Aurora MySQL バージョン 2) または mysql.rds_reset_external_source (Aurora MySQL バージョン 3) ストアドプロシージャを実行して、レプリケーション設定を削除できます。

7. レプリカをモニタリングする

Aurora MySQL DB クラスターと MySQL との間のレプリケーションを設定する場合、Aurora MySQL DB クラスターがレプリカターゲットであれば、そのクラスターのフェイルオーバーイベントをモニタリングする必要があります。フェイルオーバーが発生すると、レプリカターゲットである DB クラスターが、新しいホスト上に別のネットワークアドレスで再作成されます。フェイルオーバーイベントをモニタリングする方法については、「Amazon RDS イベント通知の操作」を参照してください。

また、レプリカターゲットがどれほどレプリケーションソースに遅れをとっているかをモニタリングするには、レプリカターゲットに接続して、SHOW SLAVE STATUS (Aurora MySQL バージョン 2) または SHOW REPLICA STATUS (Aurora MySQL バージョン 3) コマンドを実行します。このコマンドの出力の Seconds Behind Master フィールドに、マスターからレプリカターゲットへのコピーの進行状況が示されます。

レプリケーション出典とレプリケーションターゲット間でのパスワードの同期

SQL ステートメントを使用してレプリケーション出典のユーザーアカウントとパスワードを変更すると、それらの変更はレプリケーションターゲットに自動的にレプリケートされます。

AWS Management Console、AWS CLI、または RDS API を使用してレプリケーション出典のマスターパスワードを変更した場合、それらの変更はレプリケーションターゲットに自動的にレプリケートされません。出典システムとターゲットシステム間でマスターユーザーとマスターパスワードを同期する場合は、レプリケーションターゲットに対して同様の変更を自分で行う必要があります。

Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーションの停止

MySQL DB インスタンス、外部 MySQL データベース、または別の Aurora DB クラスターでのバイナリログのレプリケーションを停止するには、このトピックの後で詳しく説明するステップに従ってください。

1. レプリカターゲットでバイナリログのレプリケーションを停止する

2. レプリケーション出典のバイナリログ記録を無効にする

1. レプリカターゲットでバイナリログのレプリケーションを停止する

データベースエンジンのバイナリログレプリケーションを停止するには、以下の説明を参照してください。

2. レプリケーション出典のバイナリログ記録を無効にする

次の表の説明に従って、データベースエンジンのレプリケーションソースで、バイナリログを無効にします。

Amazon Aurora を使用した MySQL データベースの読み取りスケーリング

MySQL DB インスタンスで Amazon Aurora を使用することで、Amazon Aurora の読み取りスケーリング機能を活用して MySQL DB インスタンスの読み取りワークロードを拡張できます。Aurora を使用して MySQL DB インスタンスの読み取りを拡張するには、Amazon Aurora MySQL DB クラスターを作成し、MySQL DB インスタンスのリードレプリカに指定します。これは、RDS for MySQL DB インスタンス、または Amazon RDS の外部で実行されている MySQL データベースに適用されます。

Amazon Aurora DB クラスターの作成については、「Amazon Aurora DB クラスターの作成」を参照してください。

MySQL DB インスタンスと Amazon Aurora DB クラスターの間でレプリケーションを設定するときは、以下のガイドラインに従ってください。

  • Amazon Aurora DB クラスターを参照するときは、Amazon Aurora MySQL DB クラスターのエンドポイントアドレスを使用します。フェイルオーバーが発生すると、Aurora MySQL DB クラスターのプライマリインスタンスに昇格された Aurora レプリカで、引き続きこの DB クラスターのエンドポイントアドレスが使用されます。

  • ライターインスタンスのバイナリログが Aurora レプリカに適用されたことを確認するまで、これらのバイナリログを保持します。このメンテナンスによって、障害発生時にライターインスタンスを復元できます。

重要

自己管理型レプリケーションを使用する場合、ユーザー自身で発生する可能性のあるすべてのレプリケーションの問題をモニタリングし、解決する必要があります。詳細については、「リードレプリカ間の遅延の診断と解決」を参照してください。

注記

Amazon Aurora MySQL DB クラスターでレプリケーションを開始するために必要なアクセス許可は制限されており、Amazon RDS マスターユーザーは使用できません。このため、Aurora MySQL DB クラスターと MySQL DB インスタンスの間でレプリケーションを設定するには、mysql.rds_set_external_master (Aurora MySQL バージョン 2) または mysql.rds_set_external_source (Aurora MySQL バージョン 3) と mysql.rds_start_replication プロシージャを使用する必要があります。

外部のソースインスタンスと Aurora MySQL DB クラスターの間でレプリケーションを開始する

  1. 出典 MySQL DB インスタンスを読み取り専用にします。

    mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;

  2. 出典 MySQL DB インスタンスで SHOW MASTER STATUS コマンドを実行して、binlog の場所を特定します。以下の例のような出力を受け取ります。

    File                        Position
------------------------------------
 mysql-bin-changelog.000031      107
------------------------------------

  3. mysqldump を使用して、外部の MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターにデータベースをコピーします。大規模なデータベースの場合、Amazon Relational Database Service ユーザーガイドの「ダウンタイムを短縮して MySQL または MariaDB DB インスタンスにデータをインポートする」の手順を使用することが必要になる場合があります。

    Linux、macOS、Unix の場合:

    mysqldump \
    --databases <database_name> \
    --single-transaction \
    --compress \
    --order-by-primary \
    -u <local_user> \
    -p <local_password> | mysql \
        --host aurora_cluster_endpoint_address \
        --port 3306 \
        -u <RDS_user_name> \
        -p <RDS_password>

    Windows の場合:

    mysqldump ^
    --databases <database_name> ^
    --single-transaction ^
    --compress ^
    --order-by-primary ^
    -u <local_user> ^
    -p <local_password> | mysql ^
        --host aurora_cluster_endpoint_address ^
        --port 3306 ^
        -u <RDS_user_name> ^
        -p <RDS_password>
    注記

    -p オプションと入力するパスワードの間にスペースがないことを確認します。

    --host コマンドで、--user (-u)、--port、-p、mysql オプションを使用して、Aurora DB クラスターに接続するためのホスト名、ユーザー名、ポート、パスワードを指定します。このホスト名は、Amazon Aurora DB クラスターのエンドポイントの DNS 名 (例えば mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com) です。エンドポイントの値は、Amazon RDS マネジメントコンソールでクラスターの詳細を確認できます。

  4. もう一度出典 MySQL DB インスタンスを書き込み可能にします。

    mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;

    レプリケーションで使用するバックアップの作成の詳細については、MySQL ドキュメントの Backing up a source or replica by making it read only を参照してください。

  5. Amazon RDS マネジメントコンソールで、出典 MySQL データベースをホストするサーバーの IP アドレスを、Amazon Aurora DB クラスターの VPC セキュリティグループに追加します。VPC セキュリティグループの変更方法の詳細については、Amazon Virtual Private Cloudユーザーガイドの「VPC のセキュリティグループ」を参照してください。

    出典 MySQL インスタンスと通信できるようにするために、Amazon Aurora DB クラスターの IP アドレスからの接続を許可するようにローカルネットワークを設定することも必要になる場合があります。Amazon Aurora DB クラスターの IP アドレスを確認するには、host コマンドを使用します。

    host <aurora_endpoint_address>

    このホスト名は、Amazon Aurora DB クラスターのエンドポイントからの DNS 名です。

  6. 選択したクライアントを使用して、外部の MySQL インスタンスに接続し、レプリケーションに使用される MySQL ユーザーを作成します。このアカウントはレプリケーション専用に使用され、セキュリティを強化するためにドメインに制限する必要があります。次に例を示します。

    CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY '<password>';

  7. 外部の MySQL インスタンスについて、REPLICATION CLIENT と REPLICATION SLAVE の特権をレプリケーションユーザーに付与します。例えば、すべてのデータベースに対する REPLICATION CLIENT および REPLICATION SLAVE 権限を "repl_user" ユーザーに付与するには、以下のコマンドを実行します。

    GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
    IDENTIFIED BY '<password>';

  8. レプリケーションを設定する前に、Aurora MySQL DB クラスターの手動スナップショットをリードレプリカに指定します。DB クラスターをリードレプリカとしてレプリケーションを再構築する必要がある場合は、このスナップショットから Aurora MySQL DB クラスターを復元でき、MySQL DB インスタンスから新しい Aurora MySQL DB クラスターにデータをインポートする必要はありません。

  9. Amazon Aurora DB クラスターをレプリカとして指定します。Amazon Aurora DB クラスターにマスターユーザーとして接続し、mysql.rds_set_external_master (Aurora MySQL バージョン 2) または mysql.rds_set_external_source (Aurora MySQL バージョン 3) と mysql.rds_start_replication プロシージャを使用して、ソース MySQL データベースをレプリケーションマスターとして指定します。

    ステップ 2 で特定したマスターログファイル名とマスターログの場所を使用します。次に例を示します。

    For Aurora MySQL version 2:
CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306,
    'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0);

For Aurora MySQL version 3:
CALL mysql.rds_set_external_source ('mymasterserver.mydomain.com', 3306,
    'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0);

  10. Amazon Aurora DB クラスターで、mysql.rds_start_replication プロシージャを呼び出してレプリケーションを開始します。

    CALL mysql.rds_start_replication;

出典 MySQL DB インスタンスと Amazon Aurora DB クラスター間のレプリケーションが確立されると、Aurora レプリカを Amazon Aurora DB クラスターに追加できます。その後で、Aurora レプリカに接続してデータの読み取りを拡張できます。Aurora レプリカの作成については、「DB クラスターに Aurora レプリカを追加する」を参照してください。

バイナリログのレプリケーションの最適化

次に、Aurora MySQL でバイナリログのレプリケーションのパフォーマンスを最適化し、関連する問題のトラブルシューティングを行う方法について説明します。

ヒント

この説明は、MySQL バイナリログのレプリケーションメカニズムとその仕組みに精通していることを前提としています。背景情報については、MySQL ドキュメントの「レプリケーション実装ガイド」を参照してください。

マルチスレッドバイナリログレプリケーション (Aurora MySQL バージョン 3 以降)

マルチスレッドのバイナリログレプリケーションでは、SQL スレッドはリレーログからイベントを読み取り、SQL ワーカースレッドが適用されるようにキューに入れます。SQL ワーカースレッドは、コーディネータスレッドによって管理されます。バイナリログイベントは、可能な場合はパラレルに適用されます。

Aurora MySQL インスタンスがバイナリログレプリケーションを使用するように構成されている場合、レプリカインスタンスはデフォルトでシングルスレッドレプリケーションを使用します。マルチスレッドレプリケーションを有効にするには、カスタムパラメータグループの replica_parallel_workers パラメータを 0 より大きい値に設定します。

以下の構成オプションを使用して、マルチスレッドレプリケーションを微調整することができます。使用量に関する情報については、MySQL リファレンスマニュアルのレプリケーションとバイナリログのオプションと可変を参照してください。

最適な構成は、いくつかの要因によって異なります。例えば、バイナリログレプリケーションのパフォーマンスは、データベースワークロードの特性と、レプリカが実行されている DB インスタンスクラスの影響を受けます。したがって、新しいパラメータ設定を本番インスタンスに適用する前に、これらの構成パラメータに対するすべての変更を徹底的にテストすることをお勧めします。

  • replica_parallel_workers

  • replica_parallel_type

  • replica_preserve_commit_order

  • binlog_transaction_dependency_tracking

  • binlog_transaction_dependency_history_size

  • binlog_group_commit_sync_delay

  • binlog_group_commit_sync_no_delay_count

バイナリログレプリケーションの最適化 (Aurora MySQL 2.10 以降)

Aurora MySQL 2.10 以降では、Aurora は、バイナリログのレプリケーションにバイナリログ I/O キャッシュと呼ばれる最適化を自動的に適用します。最後にコミットされたバイナリログイベントをキャッシュすることにより、この最適化は、バイナリログ出典インスタンスでのフォアグラウンドトランザクションへの影響を制限しながら、バイナリログのダンプスレッドのパフォーマンスを向上するように設計されています。

注記

この機能に使用されるこのメモリは、MySQL binlog_cache 設定とは無関係です。

この機能は、db.t2 および db.t3 インスタンスクラスを使用するAurora DB インスタンスには適用されません。

この最適化を有効にするために、設定パラメータを調整する必要はありません。特に、以前の Aurora MySQL バージョンで設定パラメータ aurora_binlog_replication_max_yield_seconds をゼロ以外の値に調整する場合は、Aurora MySQL 2.10 以降ではゼロに戻します。

ステータス可変 aurora_binlog_io_cache_reads および aurora_binlog_io_cache_read_requests は Aurora MySQL 2.10 以降で使用できます。これらのステータス可変は、バイナリログ I/O キャッシュからデータが読み込まれる頻度をモニタリングするのに役立ちます。

  • aurora_binlog_io_cache_read_requests はキャッシュからのバイナリログ I/O 読み取りリクエストの数を示します。

  • aurora_binlog_io_cache_reads はキャッシュから情報を取得するバイナリログ I/O 読み取り数を示します。

次の SQL クエリは、キャッシュされた情報を利用するバイナリログ読み取りリクエストの割合を計算します。この場合、比率が 100 に近づくほど、より良好であることを意味します。

mysql> SELECT
  (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
    WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads')
  / (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
    WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests')
  * 100
  as binlog_io_cache_hit_ratio;
+---------------------------+
| binlog_io_cache_hit_ratio |
+---------------------------+
|         99.99847949080622 |
+---------------------------+

バイナリログ I/O キャッシュ機能には、バイナリログのダンプスレッドに関連する新しいメトリクスも含まれています。ダンプスレッドは、新しいバイナリログレプリカがバイナリログ出典インスタンスに接続したときに作成されるスレッドです。

ダンプスレッドメトリクスは、60 秒ごとにプレフィックス [Dump thread metrics] を伴ってデータベースログに出力されます。メトリクスには、Secondary_id、Secondary_uuid、バイナリログのファイル名、各レプリカが読み込んでいる位置など、各バイナリログのレプリカの情報が含まれます。メトリクスには、レプリケーション出典とレプリカの間の距離をバイト単位で表す Bytes_behind_primary も含まれます。このメトリクスは、レプリカ I/O スレッドのラグを測定します。この数値は、バイナリログのレプリカの seconds_behind_master メトリクスによって表されるレプリカ SQL 適用元スレッドのラグとは異なります。距離が減少するか増加するかを確認することで、バイナリログレプリカが出典に追いついているのか、遅れているのかを判断できます。

バイナリログレプリケーションの最適化 (Aurora MySQL バージョン 2～2.09)

Aurora MySQL のバイナリログのレプリケーションを最適化するには、以下のクラスターレベルの最適化パラメータを調整します。これらのパラメータは、バイナリログの出典インスタンスのレイテンシーとレプリケーションラグの間の適切なバランスを特定するのに役立ちます。

  • aurora_binlog_use_large_read_buffer

  • aurora_binlog_read_buffer_size

  • aurora_binlog_replication_max_yield_seconds

注記

MySQL 5.7 互換クラスターの場合、Aurora MySQL バージョン 2 から 2.09.* でこれらのパラメータを使用できます。Aurora MySQL 2.10.0 以降では、これらのパラメータはバイナリログ I/O キャッシュの最適化によって置き換えられ、それらを使用する必要はありません。

大きな読み取りバッファと最大収量の最適化の概要

クラスターが多数のトランザクションを処理している間、バイナリログのダンプスレッドが Aurora クラスターボリュームにアクセスすると、バイナリログレプリケーションのパフォーマンスが低下することがあります。パラメータ aurora_binlog_use_large_read_buffer、aurora_binlog_replication_max_yield_seconds、aurora_binlog_read_buffer_size を使用すると、このタイプの競合を最小限に抑えることができます。

例えばaurora_binlog_replication_max_yield_seconds が 0 より大きい値に設定され、ダンプスレッドの現在のバイナリログファイルがアクティブな状況にあるとします。この場合、バイナリログのダンプスレッドは、トランザクションによって現在のバイナリログファイルがいっぱいになるまで、指定された秒数待ちます。この待機期間により、各バイナリログイベントを個別にレプリケートすることによって発生する可能性のある競合が回避されます。ただし、それによりバイナリログレプリカのレプリカラグが増加します。これらのレプリカは、aurora_binlog_replication_max_yield_seconds 設定と同じ秒数だけ出典より遅れる可能性があります。

現在のバイナリログファイルとは、スレッドダンプがレプリケーションを実行するために現在読み込んでいるバイナリログファイルのことです。バイナリログファイルが更新中または受信トランザクションによる更新のために開かれているとき、バイナリログファイルはアクティブであると見なします。Aurora MySQL がアクティブなバイナリログファイルでいっぱいになると、MySQL が新しいバイナリログファイルを作成して切り替えます。古いバイナリログファイルは非アクティブになります。受信トランザクションによって更新されることはありません。

注記

これらのパラメータを調整する前に、トランザクションのレイテンシーとスループットを長期間測定してください。バイナリログレプリケーションのパフォーマンスは安定しており、競合が時折発生する場合でも低レイテンシーとなります。

aurora_binlog_use_large_read_buffer

このパラメータが 1 に設定されている場合、パラメータ aurora_binlog_read_buffer_size および aurora_binlog_replication_max_yield_seconds の設定に基づいて、Aurora MySQL がバイナリログのレプリケーションを最適化します。aurora_binlog_use_large_read_buffer が 0 の場合、Aurora MySQL はパラメータ aurora_binlog_read_buffer_size および aurora_binlog_replication_max_yield_seconds の値を無視します。

aurora_binlog_read_buffer_size

読み取りバッファが大きいバイナリログのスレッドダンプは、I/O ごとにより多くのイベントを読み取ることで、読み取り I/O オペレーションの数を最小化しています。読み取りバッファのサイズは、aurora_binlog_read_buffer_size パラメータで設定します。読み取りバッファが大きいと、大量のバイナリログデータを生成するワークロードのバイナリログの競合を減らすことができます。

注記

このパラメータは、クラスターにも設定 aurora_binlog_use_large_read_buffer=1 がある場合にのみ有効です。

読み取りバッファサイズを拡張しても、バイナリログのレプリケーションのパフォーマンスに影響はありません。バイナリログのダンプスレッドは、読み取りバッファを満たすトランザクションの更新を待ちません。

aurora_binlog_replication_max_yield_seconds

ワークロードに必要なトランザクションのレイテンシーが低く、レプリケーションラグを許容できる場合は、aurora_binlog_replication_max_yield_seconds パラメータを増やすことができます。このパラメータにより、クラスター内のバイナリログレプリケーションの最大収率のプロパティが制御されます。

注記

このパラメータは、クラスターにも設定 aurora_binlog_use_large_read_buffer=1 がある場合にのみ有効です。

Aurora MySQL は、aurora_binlog_replication_max_yield_seconds パラメータ値への変更をただちに認識します。DB インスタンスを再起動する必要はありません。ただし、この設定を有効にすると、現在のバイナリログファイルが最大サイズの 128 MB に達し、新しいファイルにローテーションされた場合にのみ、ダンプスレッドの生成がスタートされます。

関連パラメータ

次の DB クラスターパラメータを使用して、バイナリログの最適化を有効にします。

パラメータ デフォルト 有効な値 Description
aurora_binlog_use_large_read_buffer 1 0、1 レプリケーション改善の機能を有効化するスイッチ。値が 1 のとき、バイナリログのダンプスレッドによって、バイナリログのレプリケーションに aurora_binlog_read_buffer_size が使用されます。それ以外の場合は、デフォルトのバッファサイズ (8K) が使用されます。Aurora MySQL バージョン 3 では使用されません。
aurora_binlog_read_buffer_size 5242880 8192-536870912 パラメータ aurora_binlog_use_large_read_buffer が 1 に設定されている場合に、バイナリログのダンプスレッドで使用される読み取りバッファサイズ。Aurora MySQL バージョン 3 では使用されません。
aurora_binlog_replication_max_yield_seconds 0 0～36000

Aurora MySQL バージョン 2.07.* の場合、受け入れられる最大値は 45 です。2.09 以降のバージョンでは、より高い値に調整できます。

バージョン 2 の場合、このパラメータは、パラメータ aurora_binlog_use_large_read_buffer が 1 に設定されている場合にのみ機能します。

バイナリログレプリケーションの最大収率メカニズムの有効化

次のように、バイナリログレプリケーションの最大収率の最適化を有効にすることができます。これにより、バイナリログの出典インスタンスでのトランザクションのレイテンシーが最小限に抑えられます。ただし、レプリケーションラグが大きくなる場合があります。

Aurora MySQL クラスターのバイナリログ最大収率の最適化を有効にするには

  1. DB クラスターパラメータグループを作成または編集するには、以下のパラメータ設定を使用します。

    • aurora_binlog_use_large_read_buffer: ON または 1 値で有効化します。

    • aurora_binlog_replication_max_yield_seconds: 0 より大きい値を指定します。

  2. DB クラスターのパラメータグループを、バイナリログの出典として機能する Aurora MySQL クラスターに関連付けます。そのためには、「パラメータグループを使用する」の手順に従います。

  3. パラメータの変更が有効なっていることを確認します。これを行うには、バイナリログの出典インスタンスで以下のクエリを実行します。

    SELECT @@aurora_binlog_use_large_read_buffer, @@aurora_binlog_replication_max_yield_seconds;

    出力は次のようになります。

    +---------------------------------------+-----------------------------------------------+
| @@aurora_binlog_use_large_read_buffer | @@aurora_binlog_replication_max_yield_seconds |
+---------------------------------------+-----------------------------------------------+
|                                     1 |                                            45 |
+---------------------------------------+-----------------------------------------------+

バイナリログのレプリケーションを無効化する最大収率の最適化

以下のように、バイナリログのレプリケーションの最大収率の最適化を無効化することができます。これにより、レプリケーションラグが最小限に抑えられます。ただし、バイナリログの出典インスタンスでのトランザクションのレイテンシーが高くなることがあります。

Aurora MySQL クラスターの最大収率の最適化を無効化するには

  1. Aurora MySQL クラスターに関連付けられている DB クラスターのパラメータグループで、aurora_binlog_replication_max_yield_seconds が 0 に設定されていることを確認します。パラメータグループを使用して設定パラメータの設定の詳細については、「パラメータグループを使用する」を参照してください。

  2. パラメータの変更が有効なっていることを確認します。これを行うには、バイナリログの出典インスタンスで以下のクエリを実行します。

    SELECT @@aurora_binlog_replication_max_yield_seconds;

    出力は次のようになります。

    +-----------------------------------------------+
| @@aurora_binlog_replication_max_yield_seconds |
+-----------------------------------------------+
|                                             0 |
+-----------------------------------------------+

大きい読み取りバッファを無効化する

以下のように、大きい読み取りバッファの機能全体を無効化することができます。

Aurora MySQL クラスターで大きいバイナリログの読み取りバッファを無効化するには

  1. aurora_binlog_use_large_read_buffer を OFF または 0 にリセットします。

    Aurora MySQL クラスターに関連付けられている DB クラスターのパラメータグループで、aurora_binlog_use_large_read_buffer が 0 に設定されていることを確認します。パラメータグループを使用して設定パラメータの設定の詳細については、「パラメータグループを使用する」を参照してください。

  2. バイナリログの出典インスタンスで、以下のクエリを実行します。

    SELECT @@ aurora_binlog_use_large_read_buffer;

    出力は次のようになります。

    +---------------------------------------+
| @@aurora_binlog_use_large_read_buffer |
+---------------------------------------+
|                                     0 |
+---------------------------------------+

拡張バイナリログ記録の設定

拡張バイナリログを使用すると、バイナリログを有効にすることによるコンピューティングパフォーマンスのオーバーヘッドを、場合によっては最大 50% まで削減できます。拡張バイナリログを使用すると、このオーバーヘッドを約 13% まで削減できます。オーバーヘッドを減らすために、拡張バイナリログはバイナリログとトランザクションログをストレージに並行に書き込みます。これにより、トランザクションコミット時に書き込まれるデータが最小限に抑えられます。

また、拡張バイナリログを使用すると、コミュニティ MySQL バイナリログと比較して、再起動およびフェイルオーバー後のデータベースの回復時間が最大 99% 向上します。拡張バイナリログは既存のバイナリログベースのワークロードと互換性があり、コミュニティ MySQL バイナリログと同じ方法で操作できます。

拡張バイナリログは Aurora MySQL 3.03.1 バージョン (MySQL 8.0.26 と互換) 以降で利用できます。

拡張バイナリログパラメータの設定

拡張バイナリログパラメータをオン/オフにすることで、コミュニティ MySQL バイナリログと拡張バイナリログを切り替えることができます。既存のバイナリログコンシューマーは、バイナリログファイルシーケンスにギャップがなく、引き続きバイナリログファイルを読み込んで使用できます。

拡張バイナリログを無効化するには
パラメータ デフォルト 説明
binlog_format – binlog_format パラメータを、選択したバイナリログ形式に設定して、拡張バイナリログをオンにします。binlog_format parameter がオフに設定されていないことを確認してください。詳細については、「Aurora MySQL バイナリログの設定」を参照してください。
aurora_enhanced_binlog 0 Aurora MySQL クラスターに関連付けられている DB クラスターのパラメータグループで、このパラメータの値を 1 に設定します。このパラメータの値を変更する場合、DBClusterParameterGroupStatus 値が pending-reboot と表示されている状態でライターインスタンスを再起動する必要があります。
binlog_backup 1 拡張バイナリログをオンにするには、このパラメータをオフにしてください。そのためには、このパラメータの値を 0 に設定します。
binlog_replication_globaldb 1 拡張バイナリログをオンにするには、このパラメータをオフにしてください。そのためには、このパラメータの値を 0 に設定します。
重要

binlog_backup と binlog_replication_globaldb パラメータは、拡張バイナリログを使用する場合にのみオフにできます。

拡張バイナリログをオフにするには
パラメータ 説明
aurora_enhanced_binlog Aurora MySQL クラスターに関連付けられている DB クラスターのパラメータグループで、このパラメータの値を 0 に設定します。このパラメータの値を変更する際は必ず、DBClusterParameterGroupStatus 値が pending-reboot と表示されている状態でライターインスタンスを再起動する必要があります。
binlog_backup 拡張バイナリログをオフにするには、このパラメータをオンにしてください。そのためには、このパラメータの値を 1 に設定します。
binlog_replication_globaldb 拡張バイナリログをオフにするには、このパラメータをオンにしてください。そのためには、このパラメータの値を 1 に設定します。

拡張バイナリログがオンになっているかどうかを確認するには、MySQL クライアントで次のコマンドを実行します。

mysql>show status like 'aurora_enhanced_binlog';
              
+------------------------+--------+
| Variable_name          | Value  |
+------------------------+--------+
| aurora_enhanced_binlog | ACTIVE |
+------------------------+--------+
1 row in set (0.00 sec)

拡張バイナリログがオンになっている場合、aurora_enhanced_binlog の出力は ACTIVE と表示されます。

その他の関連パラメータ

拡張バイナリログを有効にすると、次のパラメータが影響を受けます。

  • max_binlog_size パラメータは表示されますが、変更できません。デフォルト値 134217728 は、拡張バイナリログがオンになったときに 268435456 に自動調整されます。

  • コミュニティ MySQL バイナリログとは異なり、拡張バイナリログがオンになっていても、binlog_checksum は動的パラメータとして動作しません。このパラメータへの変更を有効にするには、ApplyMethod が immediate の場合にも DB クラスターを手動で再起動する必要があります。

  • binlog_order_commits パラメータに設定した値は、拡張バイナリログがオンになっているときのコミットの順序には影響しません。コミットは常に順序付けられ、それ以上パフォーマンスへの影響はありません。

拡張バイナリログとコミュニティ MySQL バイナリログの違い

拡張バイナリログは、コミュニティ MySQL バイナリログと比較したとき、クローン、バックアップ、Aurora グローバルデータベースとのインタラクションが異なります。拡張バイナリログを使用する前に、次の違いを理解しておくことをお勧めします。

  • ソース DB クラスターの拡張バイナリログファイルは、クローンされた DB クラスターでは使用できません。

  • 拡張バイナリファイルは Aurora バックアップには含まれていません。そのため、DB クラスターに保持期間が設定されていても、DB クラスターを復元した後は、ソース DB クラスターの拡張バイナリログファイルを使用できません。

  • Aurora グローバルデータベースで使用する場合、プライマリ DB クラスターの拡張バイナリログファイルはセカンダリリージョンの DB クラスターに複製されません。

例

次の例は、拡張バイナリログとコミュニティ MySQL バイナリログの違いを示しています。

復元またはクローンされた DB クラスター上

拡張バイナリログがオンになっている場合、復元またはクローンされた DB クラスターでは過去のバイナリログファイルを使用できません。復元またはクローン操作の後、バイナリログがオンになっている場合、新しい DB クラスターは 1 (mysql-bin-changelog.000001) から始まる独自のバイナリログファイルのシーケンスの書き込みを開始します。

復元またはクローン操作後に拡張バイナリログを有効にするには、復元またはクローンされた DB クラスターに必要な DB クラスターパラメーターを設定します。詳細については、「拡張バイナリログパラメータの設定」を参照してください。

例 拡張バイナリログがオンになっているときに実行されるクローンまたは復元操作

ソース DB クラスター:

mysql> show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        |
| mysql-bin-changelog.000003 |       156 | No        |
| mysql-bin-changelog.000004 |       156 | No        | --> Enhanced Binlog turned on
| mysql-bin-changelog.000005 |       156 | No        | --> Enhanced Binlog turned on
| mysql-bin-changelog.000006 |       156 | No        | --> Enhanced Binlog turned on
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)

復元またはクローンされた DB クラスターでは、拡張バイナリログがオンになっていても、バイナリログファイルはバックアップされません。バイナリログデータの不連続性を避けるため、拡張バイナリログを有効にする前に書き込まれたバイナリログファイルも使用できません。

mysql>show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        | --> New sequence of Binlog files
+----------------------------+-----------+-----------+ 
1 row in set (0.00 sec)
例 拡張バイナリログがオフになっているときに実行されるクローンまたは復元操作

ソース DB クラスター:

mysql>show binary logs;
                                                
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000003 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)

復元またはクローンされた DB クラスターでは、拡張バイナリログをオフにした後に書き込まれたバイナリログファイルを使用できます。

mysql>show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
1 row in set (0.00 sec)

Amazon Aurora Global Database で

Amazon Aurora Global Database では、プライマリ DB クラスターのバイナリログデータはセカンダリ DB クラスターに複製レプリケートされません。クロスリージョンフェイルオーバープロセスの後、新たに昇格されたプライマリ DB クラスターでバイナリログデータを使用できなくなります。バイナリログがオンになっている場合、新たに昇格された DB クラスターは 1 (mysql-bin-changelog.000001) から始まる独自のバイナリログファイルのシーケンスを開始します。

フェイルオーバー後に拡張バイナリログを有効にするには、セカンダリ DB クラスターで必要な DB クラスターパラメータを設定する必要があります。詳細については、「拡張バイナリログパラメータの設定」を参照してください。

例 拡張バイナリログがオンになっている場合、グローバルデータベースのフェイルオーバー操作が実行されます。

古いプライマリ DB クラスター (フェイルオーバー前):

mysql>show binary logs;
                  
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        |
| mysql-bin-changelog.000003 |       156 | No        |
| mysql-bin-changelog.000004 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000005 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000006 |       156 | No        | --> Enhanced Binlog enabled
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)

新しいプライマリ DB クラスター (フェイルオーバー後):

拡張バイナリログがオンになっている場合、バイナリログファイルはセカンダリリージョンに複製されません。バイナリログデータの不連続性を避けるため、拡張バイナリログを有効にする前に書き込まれたバイナリログファイルは使用できません。

mysql>show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        | --> Fresh sequence of Binlog files
+----------------------------+-----------+-----------+ 
1 row in set (0.00 sec)
例 拡張バイナリログがオフになっている場合、グローバルデータベースのフェイルオーバー操作が実行されます。

ソース DB クラスター:

mysql>show binary logs;
                  
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000003 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)

復元またはクローンされた DB クラスター:

拡張バイナリログをオフにした後に書き込まれたバイナリログファイルは複製され、新たに格された DB クラスターで使用できます。

mysql>show binary logs;
                  
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
3 rows in set (0.00 sec)

拡張バイナリログの Amazon CloudWatch メトリクス

以下の Amazon CloudWatch メトリクスは、拡張バイナリログがオンになっている場合にのみ公開されます。

CloudWatch メトリクス 説明 単位
ChangeLogBytesUsed 拡張バイナリログで使用されるストレージ容量。 バイト
ChangeLogReadIOPs 5 分以内の、拡張バイナリログで実行される読み取り I/O オペレーションの数。 5 分あたりのカウント
ChangeLogWriteIOPs 5 分以内の、拡張バイナリログで実行される書き込みディスク I/O オペレーションの数。 5 分あたりのカウント

拡張バイナリログの制限

拡張バイナリログがオンになっている場合、Amazon Aurora DB クラスターには次の制限が適用されます。

  • 拡張バイナリログは Aurora MySQL 3.03.1 バージョン (MySQL 8.0.26 と互換) 以降でのみサポートされています。

  • プライマリ DB クラスターに書き込まれた拡張バイナリログファイルは、クローンまたは復元された DB クラスターにはコピーされません。

  • Amazon Aurora Global Database で使用する場合、プライマリ DB クラスターの拡張バイナリログファイルはセカンダリ DB クラスターに複製されません。そのため、フェイルオーバープロセス後、過去のバイナリログデータは新しいプライマリ DB クラスターで使用できなくなります。

  • 以下のバイナリログ設定パラメータは無視されます。

    • binlog_group_commit_sync_delay

    • binlog_group_commit_sync_no_delay_count

    • binlog_max_flush_queue_time

  • データベース内の破損したテーブルを削除したり、名前を変更したりすることはできません。これらのテーブルを削除するには、AWS Support にお問い合わせください。

  • 拡張バイナリログがオンになっている場合、バイナリログ I/O キャッシュは無効になります。詳細については、「バイナリログのレプリケーションの最適化」を参照してください。

    注記

    拡張バイナリログでは、バイナリログ I/O キャッシュと同様の読み取りパフォーマンスと、向上した書き込みパフォーマンスが提供されます。

  • バックトラック機能はサポートされていません。次の条件では、拡張バイナリログを DB クラスターで有効にできません。

    • バックトラック機能が現在有効になっている DB クラスター。

    • バックトラック機能が以前に有効になっていたが、無効化されていない DB クラスター。

    • ソース DB クラスターまたはバックトラック機能が有効になっているスナップショットから復元された DB クラスター。