必須瞭解的MySQL三大日誌:binlog、redo log和undo log
日誌是mysql資料庫的重要組成部分,記錄著資料庫執行期間各種狀態資訊。mysql日誌主要包括錯誤日誌、查詢日誌、慢查詢日誌、事務日誌、二進位制日誌幾大類。作為開發,我們重點需要關注的是二進位制日誌(binlog)和事務日誌(包括redo log和undo log),本文接下來會詳細介紹這三種日誌。
binlog
binlog用於記錄資料庫執行的寫入性操作(不包括查詢)資訊,以二進位制的形式儲存在磁碟中。binlog是mysql的邏輯日誌,並且由Server層進行記錄,使用任何儲存引擎的mysql資料庫都會記錄binlog日誌。
-
邏輯日誌:可以簡單理解為記錄的就是sql語句。
-
物理日誌:因為mysql資料最終是儲存在資料頁中的,物理日誌記錄的就是資料頁變更。
binlog是通過追加的方式進行寫入的,可以通過max_binlog_size引數設定每個binlog檔案的大小,當檔案大小達到給定值之後,會生成新的檔案來儲存日誌。
binlog使用場景
在實際應用中,binlog的主要使用場景有兩個,分別是主從複製和資料恢復。
-
主從複製:在Master端開啟binlog,然後將binlog傳送到各個Slave端,Slave端重放binlog從而達到主從資料一致。
-
資料恢復:通過使用mysqlbinlog工具來恢復資料。
binlog刷盤時機
對於InnoDB儲存引擎而言,只有在事務提交時才會記錄biglog,此時記錄還在記憶體中,那麼biglog是什麼時候刷到磁碟中的呢?mysql通過sync_binlog引數控制biglog的刷盤時機,取值範圍是0-N:
-
0:不去強制要求,由系統自行判斷何時寫入磁碟;
-
1:每次commit的時候都要將binlog寫入磁碟;
-
N:每N個事務,才會將binlog寫入磁碟。
從上面可以看出,sync_binlog最安全的是設定是1,這也是MySQL 5.7.7之後版本的預設值。但是設定一個大一些的值可以提升資料庫效能,因此實際情況下也可以將值適當調大,犧牲一定的一致性來獲取更好的效能。
binlog日誌格式
binlog日誌有三種格式,分別為STATMENT、ROW和MIXED。
在 MySQL 5.7.7之前,預設的格式是STATEMENT,MySQL 5.7.7之後,預設值是ROW。日誌格式通過binlog-format指定。
STATMENT
基於SQL語句的複製(statement-based replication, SBR),每一條會修改資料的sql語句會記錄到binlog中。
-
優點:不需要記錄每一行的變化,減少了binlog日誌量,節約了IO, 從而提高了效能;
-
缺點:在某些情況下會導致主從資料不一致,比如執行sysdate()、slepp()等。
ROW
基於行的複製(row-based replication, RBR),不記錄每條sql語句的上下文資訊,僅需記錄哪條資料被修改了。
-
優點:不會出現某些特定情況下的儲存過程、或function、或trigger的呼叫和觸發無法被正確複製的問題;
-
缺點:會產生大量的日誌,尤其是alter table的時候會讓日誌暴漲
MIXED
基於STATMENT和ROW兩種模式的混合複製(mixed-based replication, MBR),一般的複製使用STATEMENT模式儲存binlog,對於STATEMENT模式無法複製的操作使用ROW模式儲存binlog
redo log
為什麼需要redo log
我們都知道,事務的四大特性裡面有一個是永續性,具體來說就是隻要事務提交成功,那麼對資料庫做的修改就被永久儲存下來了,不可能因為任何原因再回到原來的狀態。
那麼mysql是如何保證一致性的呢?最簡單的做法是在每次事務提交的時候,將該事務涉及修改的資料頁全部重新整理到磁碟中。但是這麼做會有嚴重的效能問題,主要體現在兩個方面:
-
因為Innodb是以頁為單位進行磁碟互動的,而一個事務很可能只修改一個數據頁裡面的幾個位元組,這個時候將完整的資料頁刷到磁碟的話,太浪費資源了!
-
一個事務可能涉及修改多個數據頁,並且這些資料頁在物理上並不連續,使用隨機IO寫入效能太差!
因此mysql設計了redo log,具體來說就是隻記錄事務對資料頁做了哪些修改,這樣就能完美地解決效能問題了(相對而言檔案更小並且是順序IO)。
redo log基本概念
redo log包括兩部分:一個是記憶體中的日誌緩衝(redo log buffer),另一個是磁碟上的日誌檔案(redo log file)。mysql每執行一條DML語句,先將記錄寫入redo log buffer,後續某個時間點再一次性將多個操作記錄寫到redo log file。
這種先寫日誌,再寫磁碟的技術就是MySQL裡經常說到的WAL(Write-Ahead Logging) 技術。
在計算機作業系統中,使用者空間(user space)下的緩衝區資料一般情況下是無法直接寫入磁碟的,中間必須經過作業系統核心空間(kernel space)緩衝區(OS Buffer)。
因此,redo log buffer寫入redo log file實際上是先寫入OS Buffer,然後再通過系統呼叫fsync()將其刷到redo log file中,過程如下:
mysql支援三種將redo log buffer寫入redo log file的時機,可以通過innodb_flush_log_at_trx_commit引數配置,各引數值含義如下:
redo log記錄形式
前面說過,redo log實際上記錄資料頁的變更,而這種變更記錄是沒必要全部儲存,因此redo log實現上採用了大小固定,迴圈寫入的方式,當寫到結尾時,會回到開頭迴圈寫日誌。如下圖:
同時我們很容易得知,在innodb中,既有redo log需要刷盤,還有資料頁也需要刷盤,redo log存在的意義主要就是降低對資料頁刷盤的要求。在上圖中,write pos表示redo log當前記錄的LSN(邏輯序列號)位置,check point表示資料頁更改記錄刷盤後對應redo log所處的LSN(邏輯序列號)位置。
write pos到check point之間的部分是redo log空著的部分,用於記錄新的記錄;check point到write pos之間是redo log待落盤的資料頁更改記錄。當write pos追上check point時,會先推動check point向前移動,空出位置再記錄新的日誌。
啟動innodb的時候,不管上次是正常關閉還是異常關閉,總是會進行恢復操作。因為redo log記錄的是資料頁的物理變化,因此恢復的時候速度比邏輯日誌(如binlog)要快很多。
重啟innodb時,首先會檢查磁碟中資料頁的LSN,如果資料頁的LSN小於日誌中的LSN,則會從checkpoint開始恢復。
還有一種情況,在宕機前正處於checkpoint的刷盤過程,且資料頁的刷盤進度超過了日誌頁的刷盤進度,此時會出現資料頁中記錄的LSN大於日誌中的LSN,這時超出日誌進度的部分將不會重做,因為這本身就表示已經做過的事情,無需再重做。
redo log與binlog區別
由binlog和redo log的區別可知:binlog日誌只用于歸檔,只依靠binlog是沒有crash-safe能力的。但只有redo log也不行,因為redo log是InnoDB特有的,且日誌上的記錄落盤後會被覆蓋掉。因此需要binlog和redo log二者同時記錄,才能保證當資料庫發生宕機重啟時,資料不會丟失。
undo log
資料庫事務四大特性中有一個是原子性,具體來說就是 原子性是指對資料庫的一系列操作,要麼全部成功,要麼全部失敗,不可能出現部分成功的情況。
實際上,原子性底層就是通過undo log實現的。undo log主要記錄了資料的邏輯變化,比如一條INSERT語句,對應一條DELETE的undo log,對於每個UPDATE語句,對應一條相反的UPDATE的undo log,這樣在發生錯誤時,就能回滾到事務之前的資料狀態。
同時,undo log也是MVCC(多版本併發控制)實現的關鍵,這部分內容在面試中的老大難-mysql事務和鎖,一次性講清楚!中有介紹,不再贅述。