MySQL使用的是邏輯複製，一個事務在主庫執行結束後，會發送事務產生的Binlog event到備庫應用，進而保證主備的一致性。在這種架構下，對於耗時間長度的DDL，會導致備庫有顯著的複寫延遲。為解決此問題，RDS MySQL推出了DDL 即時應用功能。該功能可以在主庫執行DDL時即通知備庫執行DDL，達到主備同時執行DDL的效果，從而基本消除DDL導致的複寫延遲，保障執行個體的高可用。
功能簡介
背景介紹
邏輯複製的延遲主要由兩部分構成：Binlog event傳輸時間 + 備庫事務回放時間。對於DDL，僅產生一個Gtid_log_event和一個Query_log_event，傳輸量少，Binlog event傳輸時間可以忽略不計，所以DDL複寫延遲的主因就是執行DDL的長耗時。
RDS MySQL DDL即時應用
通過上文的分析，可以看到DDL導致複寫延遲的根因是MySQL現有架構要求必須在主庫提交DDL後，備庫才能應用。因此解決這個問題的直觀想法就是讓備庫不用等待主庫，而是和主庫並存執行DDL。
DDL即時應用功能的核心，也正是如此。在主庫開始執行DDL時，即通知備庫開始執行DDL；備庫在完成DDL的主要工作後，等待主庫的執行結果；主庫如果執行成功，則通知備庫提交DDL，主庫如果執行失敗，則通知備庫復原DDL。最終如下圖所示，DDL導致的複寫延遲被減少為通知備庫的所需一次網路傳輸耗時+DDL提交的耗時，此兩步耗時極低，一般最高為十毫秒級。
下文用BRR（binlog realtime replication）來指代該功能。
技術原理
支援版本
執行個體版本要求如下，當版本不符合要求時，可以升級升級核心小版本或升級資料庫版本。
MySQL 8.4
MySQL 8.0：核心小版本 ≥ 20250731。
使用限制
需要開啟即時傳輸功能。
支援的DDL語句類型與核心版本相關：
核心小版本 ≥ 20250731：支援 Alter Table。
核心小版本 ≥ 20251031：支援 Alter Table和 Optimize Table。
使用方法
您可以同時在主庫和備庫分別設定執行個體參數來開啟該功能。參數修改立即生效，無需重啟執行個體。
主庫參數：
loose_binlog_realtime_apply_ddl_source_enabled = ON
loose_binlog_realtime_ddl_time_limit = N （N為大於等於0的正整數，執行時間長度超過該值的DDL，才會使用BRR功能，該參數以毫秒為單位，預設值為1000）
備庫參數：
loose_binlog_realtime_apply_workers = N （N為大於等於1的正整數，此參數代表Brr Worker線程數）
最佳化效果
本測試構造包含80000000行記錄，大小23G的單表，然後對該表做重建表操作(alter table sbtest1 engine=innodb)。
最佳化效果如下圖所示，主庫在16:21:35和16:32:50 執行上述DDL。未開啟BRR時，備庫有持續277s的複寫延遲，開啟BRR時，無複寫延遲。
該測試執行個體小版本為20251031。
