RDS MySQL は、パラレルレプリケーションの待機ロジックを最適化することで、バッチデータ処理時のレプリケーション遅延を低減します。この機能は、非ピーク時間帯におけるデータの削除、整理、インポートなどのバッチ操作を伴うユースケースに最適です。
適用範囲
データベースバージョン: RDS MySQL 8.0
マイナーエンジンバージョン: 20251130 以降
操作手順
プライマリインスタンスまたは読み取り専用インスタンス上で、以下のグローバルパラメーターを設定し、loose_optimize_replica_parallelism を ON に設定します。
パラメーター名:
loose_optimize_replica_parallelism値:
ON有効化タイミング: 即時反映されます。インスタンスの再起動は不要です。
最適化の背景情報
多くのサービスでは、非ピーク時間帯にデータの削除、整理、インポートなどのタスクを実行します。これらのタスクは、通常、小規模かつ高並行性のバッチで実行されます。このアプローチは高速であり、データベース負荷を制御するために、バッチサイズおよび同時実行数を柔軟に調整できます。
バッチデータ処理中、インスタンス上では主に 2 種類のトランザクションが発生します。1 つ目は、バッチ処理向けの中規模トランザクションで、通常数千行のデータを処理します。2 つ目は、通常のビジネス運用向けの小規模トランザクションです。非ピーク期間中であっても、一部の通常のビジネス運用トランザクションは継続して発生します。これら 2 種類のトランザクションは、バイナリログ（binlog）ファイル内で交互に記録されます。同一のデータ行を変更する複数の小規模トランザクションが、2 つの中規模トランザクションの間に配置された場合、それら中規模トランザクションは並列実行できません。
上図に示すように、Trx2 および Trx5 はバッチ処理向けの中規模トランザクションです。一方、Trx3 および Trx4 は、同一のデータ行を変更する通常のビジネス運用向け小規模トランザクションです。SQL スレッドがこれらのトランザクションをディストリビューションする際、Trx2 および Trx3 は通常通りディストリビューションされますが、Trx4 のディストリビューションには、Trx3 およびそれ以前のすべてのトランザクションのコミットを待つ必要があります。その結果、Trx5 のディストリビューションは Trx2 のコミット完了後まで遅延し、Trx2 と Trx5 の並列適用が不可能になります。
したがって、バッチデータ処理中は、レプリカインスタンス上の同時実行数が非常に低くなります。多くの場合、アクティブなワーカーは 1 つだけとなり、実質的にシングルスレッドで処理されることになります。これにより、レプリケーション遅延が発生します。
最適化の効果
本テストでは、バッチデータ削除を例としています。シングルスレッドの sysbench write_only スクリプトがバックグラウンドでの小規模トランザクションを模擬し、8 つの並行スレッドがデータ削除用の SQL ステートメントを実行します。各 SQL ステートメントは 5000 行のデータを削除します。上記のグラフは、読み取り専用インスタンスにおけるレプリケーション遅延を示しています。本機能が有効化される前は、レプリカインスタンスのスループットが低く、レプリケーション遅延が増加していました。本機能を有効化後は、スループットが大幅に向上し、レプリケーション遅延が低下して最終的に追いつくまでに至ります。
仕組み
このシナリオを最適化するため、AliSQL は待機ロジックを SQL スレッドからワーカースレッドへ移動します。同一のデータ行を変更する小規模トランザクションが中規模トランザクションと混在する場合、該当する小規模トランザクションは、依存するトランザクションのコミットを待つためにワーカースレッド内で待機します。これにより、SQL スレッド内で待機して他のトランザクションのディストリビューションをブロックすることがなくなり、競合しない中規模トランザクションを並列実行可能になります。