ApsaraDB RDS:DDL レプリケーション遅延の最適化

仕組み

MySQL は論理レプリケーションを使用します。プライマリデータベースでトランザクションがコミットされると、その結果の binlog イベントがセカンダリに送信されてリプレイされます。DDL ステートメントの場合、binlog ペイロードは (1 つの Gtid_log_event と 1 つの Query_log_event で) 小さいため、転送時間はごくわずかです。ボトルネックは DDL 実行時間そのものです。プライマリがコミットするまでセカンダリは開始できません。

BRR はこの問題を根本から解決します。プライマリが DDL ステートメントを開始すると、リアルタイム伝送を介して、Brr binlog イベント (この機能で導入された新しいイベントタイプ) を直ちにセカンダリに送信します。セカンダリは、標準の MySQL Worker スレッドとは独立した専用の Brr Worker スレッドを使用して、DDL を並列で実行し始めます。セカンダリが DDL 作業の大部分を完了すると、プライマリからの結果を待機します：

• プライマリが成功した場合、セカンダリにコミットするよう通知します。

• プライマリが失敗した場合、セカンダリにロールバックするよう通知します。

レプリケーション遅延の合計は、セカンダリデータベースへのネットワーク伝送 1 回分と DDL のコミット時間にまで削減されます。通常は数十ミリ秒です。

Brr binlog イベントは binlog またはリレーログに書き込まれないため、バイナリログを消費するダウンストリームシステムには影響しません。

前提条件

BRR を有効化する前に、次を確認してください：

• インスタンスが RDS for MySQL 8.0 の 20250731 以降 のマイナーエンジンバージョンで実行されていること。必要に応じて、マイナーエンジンバージョンをアップグレードするか、データベースバージョンをアップグレードしてください。

• インスタンスでリアルタイム伝送機能が有効になっていること。

サポートされる DDL ステートメント

BRR が対象とする DDL ステートメントは、マイナーエンジンバージョンによって異なります：

BRR の有効化

インスタンスパラメーターを設定して、プライマリデータベースとセカンダリデータベースの両方で次のパラメーターを設定してください。変更は即時に反映され、インスタンスの再起動は不要です。

プライマリデータベース

セカンダリデータベース

ベンチマーク結果

次のテストでは、80,000,000 レコード (23 GB) を持つ単一のテーブルを使用し、ALTER TABLE sbtest1 ENGINE=InnoDB を実行して再構築しました。 プライマリは 16:21:35 に DDL を実行し、16:32:50 に再度実行しました。 テストインスタンスでは、マイナーエンジンバージョン 20251031 を使用しました。