Binary Log寫入流程

我們首先還是先看看官方檔案對sync_binlog設定的描述。

sync_binlog

控制 MySQL 伺服器將二進位制紀錄檔同步到磁碟的頻率。

• sync_binlog=0：禁用 MySQL 伺服器將二進位制紀錄檔同步到磁碟。相反，MySQL 伺服器依賴作業系統不時將二進位制紀錄檔重新整理到磁碟，就像它對任何其他檔案所做的那樣。此設定提供了最佳效能，但如果發生電源故障或作業系統崩潰，伺服器可能已提交尚未刷盤的事務。

• sync_binlog=1：在提交事務之前啟用二進位制紀錄檔到磁碟的同步。這是最安全的設定，但由於磁碟寫入次數增加，可能會對效能產生負面影響。在電源故障或作業系統崩潰的情況下，二進位制紀錄檔中丟失的事務僅處於準備狀態。這允許常規自動恢復回滾事務，從而保證不會從二進位制紀錄檔中丟失事務。

• sync_binlog=N, 其中是 0 或 1 以外的值：收集到N個二進位制紀錄檔提交組後，二進位制紀錄檔會同步到磁碟。在電源故障或作業系統崩潰的情況下，伺服器可能已經提交了尚未重新整理到二進位制紀錄檔的事務。由於磁碟寫入次數增加，此設定可能會對效能產生負面影響。較高的值會提高效能，但會增加資料丟失的風險。

InnoDB為了在與事務一起使用 的複製設定中獲得最大可能的永續性和一致性，請使用以下設定：

• sync_binlog=1.
• innodb_flush_log_at_trx_commit=1.

警告

許多作業系統和一些磁碟硬體欺騙了重新整理到磁碟操作。他們可能會告訴 mysqld已經發生了重新整理，即使它還沒有發生。在這種情況下，即使使用推薦的設定也無法保證事務的永續性，在最壞的情況下，斷電可能會損壞InnoDB資料。SCSI 磁碟控制器或磁碟本身中使用電池支援的磁碟快取可加快檔案重新整理速度，並使操作更安全。您還可以嘗試禁用硬體快取中磁碟寫入的快取。

小結

• sync_binlog設定型別為unsigned Integer。
• 一般不會設定為0，0依賴系統操作不定時fsync，發生電源故障或者系統崩潰的時候比較危險——事務提交了但是Binary Log缺失了。
• 設定為1比較安全，獲得最大可能的永續性和一致性，能保證後面的主從複製、恢復。但是對效能不利，當業務需要的IOPS不高可以設定。
• 設定為大於1的值目的是提高效能不是一個事務提交就fsync下，相當於批次刷盤，是比較聰明的方式，但是如果出現電源故障或者系統崩潰的時候Binary Log缺失的會比較多。如果磁碟本身使用電池支援的磁碟快取會比較安全。所以當業務需要的IOPS比較高時可以設定，但是一般也不會設定過大，可以在[100,1000]區間中。

另外我們通過sync_binlog=0的描述其實我們也可以大概能感覺到，其實當事務提交的時候雖然沒有馬上fsync，但是其實是已經write到檔案系統的page cache中了，那麼其實mysql在事務執行的時候也會有一個cache快取在事務中產生的Binary Log。

下面我們繼續看看Binary Log在事務執行時的cache相關設定。

binlog_cache_size

在事務期間儲存二進位制紀錄檔更改的記憶體緩衝區的大小。該值必須是 4096 的倍數。

在伺服器上啟用二進位制紀錄檔記錄（ log_bin系統變數設定為 ON）時，如果伺服器支援任何事務儲存引擎，則會為每個使用者端分配一個二進位制紀錄檔快取。如果事務的資料超出記憶體緩衝區中的空間，超出的資料將儲存在臨時檔案中。當伺服器上的二進位制紀錄檔加密處於活動狀態時，記憶體緩衝區未加密，但（從 MySQL 8.0.17 開始）用於儲存二進位制紀錄檔快取的任何臨時檔案都被加密。提交每個事務後，通過清除記憶體緩衝區並截斷臨時檔案（如果使用）來重置二進位制紀錄檔快取。

如果您經常使用大型事務，則可以通過減少或消除寫入臨時檔案的需要來增加此快取大小以獲得更好的效能。 Binlog_cache_use（服務狀態變數-使用Binary Log快取的事務數量）和 Binlog_cache_disk_use （服務狀態變數-使用臨時二進位制紀錄檔快取但超過binlog_cache_size值並使用臨時檔案儲存事務語句的事務數。）狀態變數可用於調整此變數的大小。請參閱第 5.4.4 節，「二進位制紀錄檔」。

binlog_cache_size僅設定事務快取的大小；語句快取的大小由 binlog_stmt_cache_size 系統變數控制。

小結

• binlog_cache_size設定型別為unsigned Integer。
• 用來指示每個事務期間用來快取Binary Log的大小，預設為32k，必須是4096的倍數。如果超過這個值會使用臨時檔案儲存。
• 業務中儘量不要使用大事務，如果事務過大需要考慮是否合理。一般不需要對binlog_cache_size進行修改，32k足夠了。
• binlog_cache_size不足夠的時候會使用臨時檔案進行儲存，但是效能會變低，我們可以設定max_binlog_cache_size=binlog_cache_size這樣就不會使用臨時檔案，下文會介紹。

max_binlog_cache_size

如果一個事務需要超過這麼多位元組的記憶體，伺服器會生成一個多語句事務需要超過 'max_binlog_cache_size' 位元組的儲存錯誤。最小值為 4096。可能的最大值為 16EiB（exbibytes）。最大推薦值為4GB；這是因為 MySQL 目前無法處理大於 4GB 的二進位制紀錄檔位置。該值必須是 4096 的倍數。

max_binlog_cache_size僅設定事務快取的大小；語句快取的上限由 max_binlog_stmt_cache_size 系統變數控制。

對談的可見性 max_binlog_cache_size匹配 binlog_cache_size系統變數的可見性；換句話說，更改其值只會影響更改值後啟動的新對談。

總結

• max_binlog_cache_size是一個安全值，一般根據伺服器可分配的記憶體進行設定。

概述

從上面的設定，我們可以得出，Binary Log大致的寫入流程：

1. 事務改在執行時，放入每個事務的Binary Log快取中。
2. 事務提交後根據設定來進行，如果是sync_binlog=1，則每次進行fsync，快取會釋放。如果是sync_binlog=0，則會直接寫入系統檔案的page cache，依賴於作業系統不時地將二進位制紀錄檔刷盤。如果sync_binlog=N(N>1)，則相當於批次刷盤，當然每個事務持有的binlog cache會進行釋放。

所以大致流程如下圖：

總結

至此我們大致瞭解了Mysql寫入Binary的流程，需要經過：每個事務持有的binlog cache -> 檔案系統的page cache -> 磁碟。可以通過sync_binlog進行控制具體執行策略。

使用

• sync_binlog：如果需要獲得最大的永續性和一致性的話就設定成1，至於效能問題可以調整硬體等其他方式；如果執行binary log允許丟失或者丟失通過其他方式控制又想基於目前伺服器資源進行優化就設定在[100,1000]區間中。
• binlog_cahe_size：前面已經提到過在實際業務中需要注意對事務粒度進行把控，絕大情況預設的32k足夠了。

推薦學習：

以上就是完全掌握MySql之寫入Binary Log的流程的詳細內容，更多請關注TW511.COM其它相關文章！