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

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

マルチスレッドバイナリログレプリケーション

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

マルチスレッドバイナリログレプリケーションは、Aurora MySQL バージョン 3 および Aurora MySQL バージョン 2.12.1 以降でサポートされています。

Aurora MySQL DB インスタンスがバイナリログレプリケーションを使用するように構成されている場合、レプリカインスタンスはデフォルトで 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 クラスターパラメータを使用して、バイナリログの最適化を有効にします。

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

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

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

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

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

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