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 クラスターを使用してレプリケートできます。

また、別の 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) を参照してください。

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

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

CALL mysql.rds_set_configuration('binlog retention hours', 144);

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

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

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

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

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

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

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

レプリケーション専用のユーザー ID をソースに作成します。次の例は、RDS for MySQL または外部の MySQL ソースデータベース用です。

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

Aurora MySQL ソースデータベースの場合、skip_name_resolveDB クラスターパラメータは 1 (ON) に設定され、変更できないため、ドメイン名の代わりにホストの IP アドレスを使用する必要があります。詳細については、MySQL ドキュメントの「skip_name_resolve」を参照してください。

mysql> CREATE USER 'repl_user'@'IP_address' IDENTIFIED BY 'password';

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

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

GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'IP_address';

GRANT USAGE ON *.* TO 'repl_user'@'IP_address' 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) ストアドプロシージャを実行して、レプリケーション設定を削除できます。

リードレプリカへのレプリケーションを停止する場所の設定

Aurora MySQL バージョン 3.04 以降では、mysql.rds_start_replication_until (Aurora MySQL バージョン 3) ストアドプロシージャを使用してレプリケーションを開始してバイナリログファイルの指定した位置で停止できます。

停止ポイントに達すると、レプリケーションは自動的に停止します。RDS イベントとして、Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure が生成されます。

GTID ベースのレプリケーションを使用する場合は、mysql.rds_start_replication_until_gtid (Aurora MySQL バージョン 3) ストアドプロシージャの代わりに、mysql.rds_start_replication_until (Aurora MySQL バージョン 3) ストアドプロシージャを実行します。GTID ベースのレプリケーションの詳細については、「Amazon Aurora MySQL の GTID ベースレプリケーションを使用する」を参照してください。

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 クラスターの間でレプリケーションを設定するときは、以下のガイドラインに従ってください。

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

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

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

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

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

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

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

Aurora MySQL バージョン 3.04 以降では、レプリケーションはデフォルトでマルチスレッド化され、replica_parallel_workers は 4 に設定されています。このパラメータはカスタムパラメータグループで変更できます。

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

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

Aurora MySQL バージョン 3.06 以降では、複数のセカンダリインデックスを持つ大きなテーブルのトランザクションをレプリケートするときにバイナリログレプリカのパフォーマンスを向上させることができます。この機能により、バイナリログレプリカにセカンダリインデックスの変更を並列で適用するスレッドプールが導入されます。この機能は aurora_binlog_replication_sec_index_parallel_workers DB クラスターパラメータによって制御されます。これにより、セカンダリインデックスの変更を適用できる並列スレッドの総数が制御されます。パラメータは、デフォルトで 0 (無効) に設定されています。この機能を有効にしてもインスタンスを再起動する必要はありません。この機能を有効にするには、進行中のレプリケーションを停止し、必要な数の並列ワーカースレッドを設定してから、レプリケーションを再開します。

また、このパラメータをグローバル変数として使用することもできます。ここで、n は並列ワーカースレッドの数です。

SET global aurora_binlog_replication_sec_index_parallel_workers=n;

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

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

この最適化を有効にするために、設定パラメータを調整する必要はありません。特に、以前の 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 キャッシュからデータが読み込まれる頻度をモニタリングするのに役立ちます。

次の 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 クラスターボリュームにアクセスすると、バイナリログレプリケーションのパフォーマンスが低下することがあります。パラメータ 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 MySQL は、aurora_binlog_replication_max_yield_seconds パラメータ値への変更をただちに認識します。DB インスタンスを再起動する必要はありません。ただし、この設定を有効にすると、現在のバイナリログファイルが最大サイズの 128 MB に達し、新しいファイルにローテーションされた場合にのみ、ダンプスレッドの生成がスタートされます。

関連パラメータ

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

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

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

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

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

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

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

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

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

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

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

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

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

拡張バイナリログがオンになっているかどうかを確認するには、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 と表示されます。

その他の関連パラメータ

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

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

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

例

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

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

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

復元またはクローン操作後に拡張バイナリログを有効にするには、復元またはクローンされた 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)
                      
                  

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)
                      
                  

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)
                      
                  

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 クラスターパラメータを設定する必要があります。詳細については、「拡張バイナリログパラメータの設定」を参照してください。

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)
                  

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)                          
                      
                  

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)
                  
                  

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 メトリクスは、拡張バイナリログがオンになっている場合にのみ公開されます。

拡張バイナリログの制限

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