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

本文轉載自查看原文 2020-12-13 13:36 602 Mysql

一、binlog 的高速緩存
二、刷盤機制
三、推薦的策略
推薦閱讀

問個問題吧！為什么你需要了解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就會丟失。