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壓力和長時間持寫鎖的問題被徹底消除。