RDS for MySQL は、パラレルレプリケーションの待機ロジックを最適化し、バッチデータ処理によって発生するレプリケーションラグを解消します。この機能は、オフピーク時間に実施するデータの削除、整理、インポートなどのバッチ操作で特に有効です。
適用条件
データベースインスタンスは、次のいずれかのバージョン要件を満たす必要があります：
RDS for MySQL 8.4
RDS for MySQL 8.0 (特定のマイナーエンジンバージョン以降)
有効化
プライマリインスタンスまたは読み取り専用インスタンスで、loose_optimize_replica_parallelism を ON に設定して、次のグローバルパラメーターを設定することができます。
パラメーター名：
loose_optimize_replica_parallelism値：
ON有効化： 設定は直ちに有効になります。インスタンスの再起動は不要です。
背景情報
多くのアプリケーションは、オフピーク時間に、同時実行数が高い小さなバッチを用いて、削除、整理、インポートなどのデータ操作を実行します。この方法は高速で、バッチサイズと同時実行数を柔軟に調整して、データベースへの影響を制御できます。
バッチデータ処理中、インスタンス上では主に 2 種類のトランザクションが共存します。1 つはバッチジョブによる中規模トランザクションで、通常は 1 トランザクションあたり数千行を処理します。もう 1 つは通常の業務処理による小規模トランザクションです。オフピーク時間であっても、通常の業務トラフィックは一定量残ります。これら 2 種類のトランザクションは binlog ファイル内で混在します。同一行を変更する複数の小規模トランザクションが、2 つの中規模トランザクションの間に挟まると、2 つの中規模トランザクションは並列に実行できません。
上図のとおり、 Trx2 と Trx5 はバッチ処理による中規模トランザクションです。 Trx3 と Trx4 は通常の業務処理による小規模トランザクションで、同一行を変更します。 SQL スレッドがこれらのトランザクションをディスパッチする際、 Trx2 と Trx3 は通常どおりディスパッチされます。 しかし、 Trx4 は、 SQL スレッドがディスパッチできるようになる前に、 Trx3 とそれ以前のすべてのトランザクションがコミットされるまで待機する必要があります。 これにより Trx5 のディスパッチが Trx2 のコミットまで遅延し、 Trx2 と Trx5 を並列に適用できなくなります。
その結果、バッチデータ処理中のレプリカの同時実行数は非常に低くなります。場合によっては 1 つのワーカースレッドしかアクティブにならず、実質的にパフォーマンスがシングルスレッド相当まで低下します。これにより、顕著なレプリケーションラグが発生します。
結果
バッチデータ削除によるテストで結果を示します。シングルスレッドの sysbench 書き込み専用スクリプトで小規模なバックグラウンドトランザクションをシミュレートし、8 つの同時スレッドで 5,000 行単位のバッチ削除を実行しました。上図は、読み取り専用インスタンス上のレプリケーションラグを示しています。機能を有効化する前は、レプリカのスループットが低く、レプリケーションラグが増加しました。機能を有効化した後は、スループットが大幅に向上し、レプリカが追いつくまでレプリケーションラグが減少しました。
仕組み
競合する小規模トランザクションが中規模トランザクションの間に挿入される場合、これらは依存関係がコミットされるのをワーカースレッド内で待機するようになりました。これにより、 SQL スレッドで待機して他のトランザクションのディスパッチをブロックすることを回避できます。その結果、競合しない中規模トランザクションが並列に実行できます。