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 パラメータを 1 より大きい値に設定します。

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

予期しない停止に対するデータベースの耐障害性を高めるには、ソースで GTID レプリケーションを有効にし、レプリカで GTID を許可することをお勧めします。GTID レプリケーションを許可するには、ソースとレプリカの両方で gtid_mode を ON_PERMISSIVE に設定します。GTID ベースのレプリケーションの詳細については、「GTID ベースレプリケーションを使用する」を参照してください。

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

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

スキーマとワークロードの特性は、レプリケーションに並行して影響を与える要因です。最も一般的な問題を次に挙げます。

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

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

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

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

これらのステータス変数 aurora_binlog_io_cache_reads と aurora_binlog_io_cache_read_requests は、バイナリログ 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 適用元スレッドのラグとは異なります。距離が減少するか増加するかを確認することで、バイナリログレプリカが出典に追いついているのか、遅れているのかを判断できます。