談談MySQL bin log的寫入機制、以及線上的引數是如何配置的

問個問題吧！為什麼你需要了解binlog的落盤機制呢？

我來回答一下：

上一篇文章提到了生產環境中你可以使用binlog做資料的恢復、審計、以及搭建主從架構的MySQL叢集。那你使用這些特性優勢的時候有沒有問自己一下，你使用的binlog是安全的嗎？會不會少記錄了一部分資料呢？因為使用一個有問題的binlog去做資料恢復、審計、搭建主從MySQL叢集的結果肯定是錯誤的！

下面，我們一起來看一下MySQL執行事物的過程中 binlog 的落盤機制。MySQL是如何保證你使用的binlog是安全的！

一、binlog 的快取記憶體

首先為大家介紹一個概念：binlog的快取記憶體

意思是：所有未commit的事物產生的binlog，都會被先記錄到binlog的快取記憶體中。等該事物被commit時，再將快取中的資料寫入binlog日誌檔案中。

快取記憶體的大小可以由引數binlog_chache_size 預設大小為：32768 ，並且每個session都有自己的獨立的快取。多個會話指間彼此不影響。

binlog_chache_size不能設定太大，否則大量事物打來後肯定會造成寶貴的記憶體資源被浪費。但是也別太小，因為當一個事物產生的日誌足夠大超過該引數設定的值時，MySQL會將快取中的binlog資料寫到臨時檔案中去。

看到這裡我們已經知道了binlog會寫入快取中，並且我們可以通過上述引數動態調整該緩衝。別急，繼續往看下，binlog何時被寫入磁碟呢？

二、刷盤機制

其實binlog寫入磁碟的機制由引數sync_binlog控制。

策略1:sync_binlog = 0

當設定sync_binlog = 0時，表示innodb不會主動控制將binlog落盤，innodb僅僅會將binlog寫入到OS Cache中，至於什麼時間將binlog刷入磁碟中完全依賴於作業系統。選這種策略，一旦作業系統當機，OS Cache中的binlog就會丟失。
策略2:sync_binlog = 1

設定sync_binlog = 1時，表示事物commit時將binlog落盤！這樣哪怕機器當機了，也能確保binlog會被寫入到磁碟中。

你有沒有覺得當我說：“當事物commit時將binlog落盤” ，這句話很模糊？？？

是的！如果你仔細品一品，這句話真的很模糊！

當然了，雖然模糊，但是上面說的策略2並沒有錯誤（MySQL官網也是這樣描述的)

為了不偏離本篇文章的主線，本篇暫時不詳細展開講 sync_binlog=1 的細節。

我計劃放在第 X 篇文章，“能談談MySQL的兩階段提交嗎？” 詳細展開，歡迎關注，敬請期待！

策略3:sync_binlog=N

這裡的N不是0，也不是1。

當N大於1時，表示開啟組提交，也就是group commit，如果你之前不層瞭解組提交的話，你可以這樣理解它：比如N=5，那MySQL就會等收集5個binlog後再將這5個binlog一口氣同步到磁碟上。好處很明顯，一次IO可以往磁碟上刷入N個binlog，IO效率會有所提升。壞處也很明顯，比如N=5，那當MySQL收集了4個binlog時，伺服器當機，這4個binlog就會丟失。

三、推薦的策略

線上環境中，推薦將日誌的刷盤策略設定成下圖這這樣。

這是也官方推薦的配置策略。這兩個引數前面都已經提到過了，想必為什麼這麼設定，你已經很清楚了！

參考：

https://dev.mysql.com/doc/refman/5.7/en/replication-options-binary-log.html

https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit

談談MySQL bin log的寫入機制、以及線上的引數是如何配置的

一、binlog 的快取記憶體

二、刷盤機制

三、推薦的策略

推薦閱讀

相關文章