聊聊 binlog 是什麼？

語言: CN / TW / HK

時間 2021-09-08 14:01:12 程式猿阿星

前言

上篇阿星詳細聊了 redo log（重做日誌），但是在MySQL資料庫中還有一種二進位制日誌叫binlog（歸檔日誌）。

redo log它是物理日誌，記錄內容是“在某個資料頁上做了什麼修改”，屬於InnoDB儲存引擎。

而binlog是邏輯日誌，記錄內容是語句的原始邏輯，類似於“給ID=2這一行的c欄位加1”，屬於MySQL Server層。

不管用什麼儲存引擎，只要發生了表資料更新，都會產生binlog日誌。

那binlog到底是用來幹嘛的？

可以說MySQL資料庫的資料備份、主備、主主、主從都離不開binlog，需要依靠binlog來同步資料，保證資料一致性。

binlog會記錄所有涉及更新資料的邏輯操作，並且是順序寫。

binlog日誌有三種格式，可以通過binlog_format引數指定。

指定statement，記錄的內容是SQL語句原文，比如執行一條update T set update_time=now() where id=1，記錄的內容如下。

同步資料時，會執行記錄的SQL語句，但是有個問題，update_time=now()這裡會獲取當前系統時間，直接執行會導致與原庫的資料不一致。

為了解決這種問題，我們需要指定為row，記錄的內容不再是簡單的SQL語句了，還包含操作的具體資料，記錄內容如下。

row格式記錄的內容看不到詳細資訊，要通過mysqlbinlog工具解析出來。

update_time=now()變成了具體的時間update_time=1627112756247，條件後面的@1、@2、@3都是該行資料第1個~3個欄位的原始值（假設這張表只有3個欄位）。

這樣就能保證同步資料的一致性，通常情況下都是指定為row，這樣可以為資料庫的恢復與同步帶來更好的可靠性。

但是這種格式，需要更大的容量來記錄，比較佔用空間，恢復與同步時會更消耗IO資源，影響執行速度。

所以就有了一種折中的方案，指定為mixed，記錄的內容是前兩者的混合。

MySQL會判斷這條SQL語句是否可能引起資料不一致，如果是，就用row格式，否則就用statement格式。

binlog的寫入時機也非常簡單，事務執行過程中，先把日誌寫到binlog cache，事務提交的時候，再把binlog cache寫到binlog檔案中。

因為一個事務的binlog不能被拆開，無論這個事務多大，也要確保一次性寫入，所以系統會給每個執行緒分配一個塊記憶體作為binlog cache。

我們可以通過binlog_cache_size引數控制單個執行緒binlog cache大小，如果儲存內容超過了這個引數，就要暫存到磁碟（Swap）。

binlog日誌刷盤流程如下

write和fsync的時機，可以由引數sync_binlog控制，預設是0。

為0的時候，表示每次提交事務都只write，由系統自行判斷什麼時候執行fsync。

雖然效能得到提升，但是機器宕機，page cache裡面的binglog會丟失。

為了安全起見，可以設定為1，表示每次提交事務都會執行fsync，就如同binlog日誌刷盤流程一樣。

最後還有一種折中方式，可以設定為N(N>1)，表示每次提交事務都write，但累積N個事務後才fsync。

在出現IO瓶頸的場景裡，將sync_binlog設定成一個比較大的值，可以提升效能。

同樣的，如果機器宕機，會丟失最近N個事務的binlog日誌。

阿星是一個熱愛技術的 Java 程式猿，公眾號 「程式猿阿星」 定期分享有趣有料的精品原創文章！

咱們都是自家人，點不點贊，在不在看什麼的，沒關係的，看開心了就好。

在看，點贊什麼的，我不是特別在意，真的，真的，別不信啊。

不三連也真的沒關係。

大夥們不要在意啊。

我是阿星，我們下期見

「其他文章」