MySQL では、プライマリインスタンスとスタンバイインスタンス間のデータ整合性を確保するために論理レプリケーションが使用されます。プライマリインスタンスでトランザクションがコミットされると、その Binlog イベントがスタンバイインスタンスに送信され、適用されます。このアーキテクチャでは、長時間実行される DDL (Data Definition Language) ステートメントが、スタンバイインスタンスで大きなレプリケーションレイテンシーを引き起こす可能性があります。この問題に対処するため、RDS MySQL ではリアルタイム DDL 適用機能が導入されています。この機能により、スタンバイインスタンスは、プライマリインスタンスと同時に DDL ステートメントの実行を開始するよう通知されます。この並列実行により、DDL に起因するレプリケーションレイテンシーがほぼ解消され、インスタンスの高可用性が確保されます。
機能概要
背景情報
論理レプリケーションにおけるレイテンシーは、主に Binlog イベントの転送時間と、スタンバイインスタンスでのトランザクションリプレイ時間の 2 つの要素で構成されます。DDL 操作では、1 つの Gtid_log_event と 1 つの Query_log_event のみが生成されるため、転送されるデータ量は少なくなります。したがって、Binlog イベントの転送時間はごくわずかです。DDL レプリケーションレイテンシーの主な原因は、DDL ステートメントの実行時間が長いことにあります。
RDS MySQL におけるリアルタイム DDL 適用
DDL に起因するレプリケーションレイテンシーの根本原因は、MySQL のアーキテクチャ上、スタンバイインスタンスが DDL ステートメントを適用する前にプライマリインスタンスでのコミットが必要となる点にあります。最も直接的な解決策は、スタンバイインスタンスがプライマリインスタンスと並列で DDL ステートメントを実行できるようにすることです。
これがリアルタイム DDL 適用機能の基本原理です。プライマリインスタンスは DDL ステートメントの実行を開始すると、同時にスタンバイインスタンスに対して同じ操作を開始するよう通知します。スタンバイインスタンスは DDL 操作の大部分を実行した後、プライマリインスタンスからの最終結果を待機します。プライマリインスタンスで操作が成功した場合はスタンバイにコミットを指示し、失敗した場合はロールバックを指示します。その結果、DDL によって発生するレプリケーションレイテンシーは、1 回のネットワーク転送時間と DDL コミット時間に短縮されます。この 2 つのステップは非常に高速で、通常は数十ミリ秒以内で完了します。
この機能は Binlog Realtime Replication (BRR) と呼ばれます。
仕組み
プライマリインスタンスは Brr binlog イベントという新しいタイプのイベントを作成し、リアルタイム転送機能を使用してスタンバイインスタンスに送信します。このイベントにより、スタンバイインスタンスは DDL を実行するよう通知され、両方のインスタンスでの同時実行が実現されます。Brr binlog イベントは Binlog やリレーログには記録されないため、binlog を利用する下流システムには影響しません。
スタンバイインスタンスは、DDL ステートメントをリアルタイムで適用するために、指定された数の Brr ワーカースレッドを作成します。これらの Brr ワーカースレッドは、MySQL の元の ワーカースレッドとは独立して動作します。
サポートされているバージョン
この機能を使用するには、インスタンスが以下のバージョン要件を満たす必要があります：インスタンスが要件を満たしていない場合は、マイナーエンジンバージョンのアップグレードまたはデータベースメジャーバージョンのアップグレードを実行できます。
MySQL 8.4
MySQL 8.0：マイナーエンジンバージョン ≥ 20250731
制限事項
リアルタイム転送機能が有効になっている必要があります。
サポートされる DDL ステートメントの種類は、マイナーエンジンバージョンによって異なります：
マイナーエンジンバージョン ≥ 20250731： Alter Table をサポート
マイナーエンジンバージョン ≥ 20251031： Alter Table および Optimize Table をサポート
操作手順
この機能を有効化するには、プライマリインスタンスとスタンバイインスタンスの両方でインスタンスパラメーターを設定します。パラメーターの変更は、インスタンスの再起動を必要とせず、即座に有効になります。
プライマリインスタンスのパラメーター：
loose_binlog_realtime_apply_ddl_source_enabled = ONloose_binlog_realtime_ddl_time_limit = N(Nは 0 以上の整数。DDL ステートメントの実行時間がこの値を超えると、BRR 機能がトリガーされます。このパラメーターの単位はミリ秒で、デフォルト値は 1000 です。)
スタンバイインスタンスのパラメーター：
loose_binlog_realtime_apply_workers = N(Nは 1 以上の整数。このパラメーターは Brr ワーカースレッドの数を指定します。)
最適化結果
このテストでは、8,000 万行、23 GB のテーブルを使用します。このテーブルに対してテーブルの再構築操作 (alter table sbtest1 engine=innodb) を実行します。
最適化結果を以下の図に示します。プライマリインスタンスは 16:21:35 と 16:32:50 に DDL ステートメントを実行しました。BRR が無効の場合、スタンバイインスタンスでは 277 秒の持続的なレプリケーションレイテンシーが発生しました。BRR を有効化すると、レプリケーションレイテンシーは解消されました。
テストインスタンスのマイナーエンジンバージョンは 20251031 でした。
