Binlog in Redo - ApsaraDB RDS

Binlog in Redo功能指在事務提交時將Binlog內容同步寫入到Redo Log中，減少對磁碟的操作，提高資料庫效能。

前提條件

執行個體版本為MySQL 8.0（核心小版本20200430或以上）。

背景資訊

在MySQL關鍵業務情境中，為了業務資料的安全，事務提交時必須即時儲存對應的Binlog和Redo Log，即以下兩個參數必須同時設定為1：

sync_binlog = 1;
innodb_flush_log_at_trx_commit = 1;

由於每個事務提交會對磁碟進行兩次I/O操作，雖然Binlog採用了Group Commit的方式合并I/O來提升效率，但兩次I/O等待的本質沒有改變，影響交易處理的效率，當使用雲端硬碟儲存時，影響會更明顯。I/O合并的效率是由同時提交的並發事務數量決定的，當並發量不夠時I/O合并的效果也不理想，表現為少量的寫操作事務提交時所需要的時間比較久，回應時間較長。

為了提高事務提交效率，AliSQL精心設計了Binlog in Redo機制（設定參數persist_binlog_to_redo = on開啟），即在事務提交時將Binlog內容同步寫入到Redo Log中。當事務提交時，只需要將Redo Log儲存到磁碟中，從而減少一次對磁碟的操作，而Binlog檔案則採用非同步方式，用單獨的線程周期性的儲存到磁碟中。在異常重啟後，系統會用Redo Log中的Binlog內容來補齊Binlog檔案。由於減少了一次I/O操作，效能得到了提升，回應時間變的更短，同時Binlog檔案儲存次數的減少，極大地降低了檔案系統因檔案長度即時變化帶來的檔案同步（fsync）壓力，也提升了檔案系統的效能。

Binlog in Redo功能不會改變Binlog的格式，基於Binlog的複製及第三方工具也不會受任何影響。

注意事項

開啟Binlog in Redo功能後，本地碟執行個體如果需要使用物理備份檔案恢複到自建資料庫，需要使用RDS提供的XtraBackup工具。安裝XtraBackup工具請參見工具準備。

參數介紹

persist_binlog_to_redo
Binlog in Redo功能開關。全域系統變數，取值：on或off。修改本參數立刻生效，不需要重啟執行個體。
說明
您只需要設定persist_binlog_to_redo = on即可正常使用Binlog in Redo功能，不需要修改其他參數（sync_binlog = 1自動失效）。
sync_binlog_interval
Binlog非同步儲存的間隔。全域系統變數，當persist_binlog_to_redo = on時生效。預設值：50，單位：毫秒（ms），通常使用預設值即可。修改本參數立刻生效，不需要重啟執行個體。

效能壓力測試

測試環境
- 應用伺服器：阿里雲ECS執行個體
- RDS執行個體規格： 32核、64 GB記憶體、ESSD雲端硬碟
- 執行個體類型：高可用系列（資料複製方式為非同步複製）
測試案例
使用的Sysbench內建用例如下：
- oltp_update_non_index
- oltp_insert
- oltp_write_only
測試結果
- oltp_update_non_index
  開啟Binlog in Redo後，QPS在低並發情境下提升顯著，延遲也較低。
- oltp_insert
  開啟Binlog in Redo後，QPS在低並發情境下提升顯著，延遲也較低。
- oltp_write_only
  開啟Binlog in Redo後，QPS在低並發情境下有所提升，延遲也較低。
- Binlog Fsync次數對比
  開啟Binlog in Redo後，Binlog fsync的次數大幅降低。

測試總結

oltp_update_non_index和oltp_insert只包含單語句事務，事務提交次數多，而oltp_write_only包含多語句事務（2個UPDATE、1個DELETE、1個INSERT），相比oltp_update_non_index和oltp_insert，事務提交次數較少，所以oltp_update_non_index和oltp_insert的效能提升比oltp_write_only更為明顯。
在低於256並發時，Binlog in Redo功能可以明顯提升效能和降低延遲。對絕大多數的實際使用情境來說，Binlog in Redo效果顯著。
Binlog in Redo功能開啟後會大幅降低Binlog fsync的次數，可以提升檔案系統的效能。