PolarDB MySQL版最佳化了大事務寫Binlog造成其他事務寫Binlog夯住的問題。本文介紹該最佳化的使用方法和使用限制。
背景資訊
開啟Binlog後，事務在提交時需要記錄Binlog，該過程如下圖所示。各個事務在執行過程中會將產生的Binlog臨時記錄在各自的Binlog Cache結構中。提交事務時，若這些事務同時提交，它們將排隊從各自的Binlog Cache結構中讀取Binlog並寫入Binlog檔案中。如果某個正在排隊的事務（Trx2）需要寫大量的Binlog，例如，Binlog的規模為1 GB，寫Binlog檔案的時間長，導致這段時間後面排隊的事務也無法寫Binlog檔案，因而無法完成提交。因此，系統在這段時間不可寫，導致出現了大量的慢SQL，進而可能導致用戶端重試或串連暴漲等問題，從而進一步加大系統壓力。
PolarDB MySQL版針對性地推出大事務最佳化方案來解決該問題，使用該最佳化方案後，大事務寫Binlog不再阻塞其它寫Binlog事務的提交，避免系統短時間不可寫入，從而產生大量寫請求慢SQL或串連暴漲等問題。
版本要求
PolarDB MySQL版產品版本需為企業版或標準版，資料庫引擎版本需為8.0.1，且小版本為8.0.1.1.42及以上。
您可以通過查詢版本號碼來確認叢集版本。
使用限制
開啟Binlog大事務最佳化後，大事務產生的Binlog將獨佔一個Binlog檔案。如下圖所示，其所在Binlog檔案的頭部除了包括Format Description Event、Previous Gtids Log Event等，還包括一個佔位Event：Ignorable Log Event，當下遊解析到該Event時，會自動忽略。
這種Binlog結構需要注意如下問題：
下遊複製節點無法使用以database並發方式的Multi-Threaded Replication，但可以使用logical clock並發方式，禁止指定
slave_parallel_workers>0,slave_parallel_type='DATABASE'，但允許指定slave_parallel_workers> 0,slave_parallel_type= 'logical_clock'。對大事務所在的Binlog檔案禁用checksum，其它Binlog檔案不受影響。
使用方法
您需要將參數loose_enable_large_trx_optimization的值設定為ON來開啟Binlog大事務最佳化機制。開啟最佳化後，通過設定參數loose_binlog_large_trx_threshold_up來定義使用這種最佳化機制的事務大小的閾值。
關於如何設定參數，請參見設定叢集參數。
參數的具體說明如下表：
參數名稱 | 層級 | 參數說明 |
loose_enable_large_trx_optimization | Global | 開啟或關閉Binlog大事務最佳化機制。取值範圍如下：
該參數修改後立即生效，無需重啟叢集。 |
loose_binlog_large_trx_threshold_up | Global | Binlog大事務最佳化的閾值。開啟Binlog大事務最佳化機制後，當單個事務產生的Binlog大小超過該閾值時，將採用最佳化的Binlog提交方式。
該參數修改後立即生效，無需重啟叢集。 |
效能對比
當叢集的儲存類型為PSL5時，叢集開啟和關閉Binlog大事務最佳化機制的效果對比如下圖所示：
可以看到，開啟Binlog大事務最佳化機制後，大事務提交的耗時被大幅縮短，提交導致的IO壓力和長時間持寫鎖的問題被徹底消除。