完全掌握MySql之寫入Binary Log的流程

本篇文章為大家帶來了關於mysql中寫入Binary Log流程的相關知識，其中包含「sync_binlog」、「binlog_cache_size」和「max_binlog_cache_size」的相關問題，希望對大家有幫助。

Binary Log寫入流程

我們首先還是先看看官方文件對sync_binlog配置的描述。

sync_binlog

#命令列格式	--sync-binlog=
#系統變數	sync_binlog
	##sync_binlog
影響範圍	Global
動態的	#Yes

SET_VAR提示適用

No

• 類型
• Integer

• #預設值

  ##1

#最小值0

• 最大
• #2^32=4294967295

#控制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.

資料。 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。 指令格式#系統變數#範圍

警告	#許多作業系統和一些磁碟硬體欺騙了刷新到磁碟操作。他們可能會告訴 mysqld已經發生了刷新，即使它還沒有發生。在這種情況下，即使使用建議的設定也無法保證交易的持久性，在最壞的情況下，斷電可能會損壞 InnoDB
下面我們繼續看看Binary Log在交易運行時的cache相關配置。	binlog_cache_size
--binlog-cache-size=
binlog_cache_size

Golbal#############動態的#######Yes############SET_VAR提示適用#### ##No############類型######Integer#############預設值#####32768##### ######最小值######4096############最大(64位元平台)######2^64=18446744073709547520##### #######最大值(32位元平台)######2^32=4294967295############區塊大小######4096#### ########

在交易期間保存二進位日誌變更的記憶體緩衝區的大小。該值必須是 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=##系統變數##max_binlog_cache_sizeGolbalYes##SET_VAR提示適用No類型Integer預設值2^ 64=184467440737095475201844674407520#4096

	#範圍
	動態的

## ###########區塊大小######4096#############

如果一個事務需要超過這麼多位元組的內存，伺服器會產生一個多語句事務需要超過 '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影片教學

#

以上是完全掌握MySql之寫入Binary Log的流程的詳細內容。更多資訊請關注PHP中文網其他相關文章！