Aurora MySQL でのバイナリログのレプリケーションの最適化
次に、Aurora MySQL でバイナリログのレプリケーションのパフォーマンスを最適化し、関連する問題のトラブルシューティングを行う方法について説明します。
ヒント
この説明は、MySQL バイナリログのレプリケーションメカニズムとその仕組みに精通していることを前提としています。背景情報については、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 インスタンスクラスの影響を受けます。したがって、新しいパラメータ設定を本番インスタンスに適用する前に、これらの構成パラメータに対するすべての変更を徹底的にテストすることをお勧めします。
-
binlog_group_commit_sync_delay -
binlog_group_commit_sync_no_delay_count -
binlog_transaction_dependency_history_size -
binlog_transaction_dependency_tracking -
replica_preserve_commit_order -
replica_parallel_type -
replica_parallel_workers
Aurora MySQL バージョン 3.06 以降では、複数のセカンダリインデックスを持つ大きなテーブルのトランザクションをレプリケートするときにバイナリログレプリカのパフォーマンスを向上させることができます。この機能により、バイナリログレプリカにセカンダリインデックスの変更を並列で適用するスレッドプールが導入されます。この機能は aurora_binlog_replication_sec_index_parallel_workers DB クラスターパラメータによって制御されます。これにより、セカンダリインデックスの変更を適用できる並列スレッドの総数が制御されます。パラメータは、デフォルトで 0 (無効) に設定されています。この機能を有効にしてもインスタンスを再起動する必要はありません。この機能を有効にするには、進行中のレプリケーションを停止し、必要な数の並列ワーカースレッドを設定してから、レプリケーションを再開します。
バイナリログのレプリケーションの最適化
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_binlog_io_cache_reads と aurora_binlog_io_cache_read_requests は、バイナリログ 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 適用元スレッドのラグとは異なります。距離が減少するか増加するかを確認することで、バイナリログレプリカが出典に追いついているのか、遅れているのかを判断できます。
