在MySQL半同步複製環境中提交大事務時，常因Binlog傳輸所需時間過長而導致半同步逾時。這會使半同步複製降級為非同步複製，引致資料可靠性下降，同時阻塞後續事務，造成業務效能抖動。為解決此問題，RDS MySQL推出了Binlog即時傳輸功能。該功能可以在大事務執行過程中就將其Binlog串流至備庫，從而在事務提交時將同步耗時降至毫秒級，保障資料高可靠與業務效能的穩定。
功能簡介
背景資訊
原生MySQL主備之間依賴單一通道傳輸Binlog。當一個大事務的Binlog佔據該通道時，會阻塞其後所有事務的Binlog傳輸，導致主庫上等待提交的事務大量堆積，執行個體出現短暫的不可寫。為了避免服務長時間不可用，MySQL引入了rpl_semi_sync_master_timeout參數。若Binlog在規定時間內未獲得備庫確認，半同步複製便會退化為非同步複製。因此，大事務可能引發兩個核心問題：
效能抖動：執行個體出現秒級不可寫，大量提交請求成為慢SQL。
可靠性下降：複製模式降級，極端情境下可能遺失資料。
RDS MySQL Binlog即時傳輸
傳統模式下，事務的Binlog在執行期間暫存於主庫的Binlog Cache，直到事務提交時才一次性寫入Binlog檔案並發送至備庫。RDS MySQL的Binlog即時傳輸功能最佳化了這一過程。對於超過特定閾值的大事務，該功能會將產生的Binlog Event從Binlog Cache中持續地發送到備庫，暫存在備庫的Relay Log Cache中。當主庫事務提交時，只需發送一個“提交”指令，備庫即可快速將快取資料寫入Relay Log檔案並返回確認。通過這種“邊執行邊傳輸”的流式設計，大事務提交時的Binlog傳輸耗時從數秒縮短至毫秒級，有效避免了傳輸瓶頸。
技術原理：Relay Log Cache的設計
為在備庫上暫存即時傳輸的Binlog Event，RDS MySQL為每個大事務設計了獨立的Relay Log Cache。在寫入資料前，系統會在Cache頭部預留一段空間，用於後續填充Relay Log Event的Header資訊，從而實現從Cache到Relay Log檔案的快速轉換。當預留空間不足或富餘時，系統會通過回退到原有邏輯或填充Empty Event等方式智能處理，確保機制的健壯性。
適用範圍
資料庫版本需滿足以下要求：
MySQL 8.4
MySQL 8.0且核心小版本在20250531及以上
使用說明
您可以同時在主庫和備庫分別設定以下全域參數來開啟該功能。參數修改立即生效，無需重啟執行個體。
開啟方式：
主庫：
loose_binlog_realtime_transmit_source_enabled=ON備庫：
loose_binlog_realtime_transmit_replica_enabled=ON
核心參數：
loose_binlog_realtime_transmit_long_transaction_limit_size作用：定義觸發即時傳輸的事務大小閾值。當一個事務產生的Binlog超過該值，其即時傳輸功能便會自動啟用。
預設值：128 MB。
最佳化效果
通過在半同步複製執行個體上疊加一個2 GB的大事務來類比高負載情境。測試結果如下圖所示：
最佳化前（原生MySQL）：提交大事務後，執行個體的QPS瞬間降至零，效能出現嚴重波動。隨後，由於半同步逾時，系統降級為非同步模式，效能雖然有所回升，但資料的可靠性卻降低。
最佳化後（RDS MySQL）：開啟Binlog即時傳輸後，即使在提交大事務期間，執行個體QPS始終保持平穩，有效避免了效能抖動和複製模式降級。
