ApsaraDB RDS：Binlog Parallel Flush

前提條件

• 執行個體版本為MySQL 8.0。

• 核心小版本：20230930或以上

  說明

  您可以在基本資料頁面的配置資訊地區查看是否有升級核心小版本按鈕。如果有按鈕，您可以單擊按鈕查看目前的版本；如果沒有按鈕，表示已經是最新版。詳情請參見升級核心小版本。

• 執行個體的sync_binlog參數不為1。

背景資訊

在MySQL中，每個事務在提交階段都要寫Binlog。這個過程是串列的，即一個事務寫完後，另一個事務才能開始寫Binlog，如上圖所示。

同時，這個過程又是很耗時的，寫Binlog之前要將Binlog Cache中儲存的所有event都解析出來，填上Checksum和log_pos，還需要產生GTID event，隨後才能將這些event寫入Binlog檔案。這個串列且耗時的過程，對執行個體的寫效能造成了很大的瓶頸。為瞭解決這個瓶頸，AliSQL引入了Binlog Parallel Flush最佳化。

最佳化詳情

Binlog Buffer

AliSQL在原有邏輯之上，引入了一個Binlog Buffer。多個線程在分配好位置之後，可以並行的將Binlog event寫到Binlog Buffer中，然後由後台線程將Binlog Buffer寫入Binlog檔案。這樣一來，原本串列的解析，填充Checksum和log_pos，產生GTID event等步驟，都可以並行的執行，極大最佳化了事務寫 Binlog的效能瓶頸。

並行組提交

在MySQL中，提交階段事務會成組地寫Binlog和Redo Log，這樣做可以最大限度地合并IO操作，提升效能。在本最佳化中，依舊保留這種組提交的思想，加入組提交後的Binlog Parallel Flush最佳化，如下圖所示。

在Binlog Parallel Flush最佳化中，每個事務需要串列地分配GTID和Binlog Buffer空間，隨後多個組可以並行地寫Binlog Buffer，在等待Redo log持久化和後台線程寫Binlog完成後，整組事務就可以提交。

Binlog持久化

在Binlog Parallel Flush最佳化中，Binlog檔案由一個後台線程周期性的進行持久化，預設持久化周期為每秒一次。

參數介紹

loose_binlog_parallel_flush

Binlog Parallel Flush的功能開關。全域系統變數，取值：on或off。修改本參數立刻生效，不需要重啟執行個體。

最佳化效果

測試環境

選取RDS MySQL四種不同規格做測試對比，如表格所示。

參數設定

測試執行個體使用高績效參數模板，該模板中兩個效能相關參數的配置為：sync_binlog = 1000、innodB_flush_log_at_trx_commit = 2。

測試指令碼

使用SysBench的oltp_update_non_index指令碼進行效能測試，測試的資料量為100張表，每張表有10萬行資料。

測試結果

測試結果如下圖所示。高並發效能下，Parallel Flush與MySQL原生的Normal Flush相比，有明顯的效能提升，峰值效能提升在10%到30%之間。