Mysql中undo、redo與binlog的區別淺析

前言

MySQL中有六種日志文件,分別是:重做日志(redo log)、回滾日志(undo log)、二進制日志(binlog)、錯誤日志(errorlog)、慢查詢日志(slow query log)、一般查詢日志(general log),中繼日志(relay log)。

其中重做日志和回滾日志與事務操作息息相關,二進制日志也與事務操作有一定的關系,這三種日志,對理解MySQL中的事務操作有著重要的意義。

  與不同引擎的關系 核心作用 生命周期   日志類型
undo log 屬於innodb引擎獨有 回滾,保證事務的“原子性”,事務日志  事務開始前,以類似“快照”的方式記錄現場  邏輯日志
redo log 屬於innodb引擎獨有 重做,保證事務的“持久性”,事務日志  事務開始後記錄,prepare階段落盤  物理日志
binlog 工作在mysql的Server層,與使用哪種引擎無關 實現主從節點數據的復制  事務執行期間記錄,commit階段完成前落盤  邏輯日志

【undo log】

事務開始之前,將當前事務版本生成 undo log(Tips:undo log 也會產生 redo log 來保證 undo log 的可靠性)。

事務提交之後,undo log 並不能立馬被刪除,而是放入待清理的鏈表,由 purge 線程判斷是否有其它事務在使用 undo 段中表的上一個事務之前的版本信息,從而決定是否可以清理 undo log 的日志空間。

數據庫事務四大特性中有一個是 原子性 ,具體來說就是 原子性是指對數據庫的一系列操作,要麼全部成功,要麼全部失敗,不可能出現部分成功的情況。

實際上, 原子性 底層就是通過undo log實現的。undo log主要記錄瞭數據的邏輯變化,比如一條INSERT語句,對應一條DELETE的undo log,對於每個UPDATE語句,對應一條相反的UPDATE的undo log,這樣在發生錯誤時,就能回滾到事務之前的數據狀態。例如,user表中原記錄如下:

id name
1 xiaoming

執行sql  update user set name = 'xiaohong' where id = 1; 的時候生成的undo log大概是update user set name = 'xiaoming' where id = 1;

同時,undo log也是MVCC(多版本並發控制)實現的關鍵。 

【redo log】

mysql是如何保證事務的持久性的呢?最簡單的做法是在每次事務提交的時候,將該事務涉及修改的數據頁全部刷新到磁盤中。但是這麼做會有嚴重的性能問題,主要體現在兩個方面:

  • 因為Innodb是以頁為單位進行磁盤交互的,而一個事務很可能隻修改一個數據頁裡面的幾個字節,這個時候將完整的數據頁刷到磁盤的話,太浪費資源瞭!
  • 一個事務可能涉及修改多個數據頁,並且這些數據頁在物理上並不連續,使用隨機IO寫入性能太差!

因此,mysql設計瞭redo log機制,並通過WAL(Write-Ahead Logging)技術進行瞭性能優化。WAL的核心就是先順序IO寫日志磁盤、再隨機IO寫數據磁盤,節省的是隨機寫磁盤的 IO 消耗。mysql 每執行一條 DML 語句,先將記錄順序追加寫入 redo log buffer並更新內存中的數據,等到有空閑線程、內存不足、Redo Log滿時再批量落盤持久化。

【binlog】

binlog是mysql的邏輯日志並且由Server層進行記錄,記錄對象為任意數據庫引擎的寫入性操作(不包括查詢)信息,以二進制的形式保存在磁盤中。

在實際應用中,binlog的主要使用場景有兩個,分別是 主從復制 和 數據恢復 。

  • 主從復制 :在Master端開啟binlog,然後將binlog發送到各個Slave端,Slave端重放binlog從而達到主從數據一致。
  • 數據恢復 :通過使用mysqlbinlog工具來恢復數據。

數據更新過程中,萬一更新數據的過程中系統出現故障異常重啟瞭,如何保證事務的持久性、原子性呢?概述如下:

  1. 記錄此次更新前數據記錄的快照現場(即寫undo log)
  2. 讀取此次更新所需要的數據入內存
  3. 在內存中更新數據(效率高)
  4. 寫redo log,並置redo log狀態為prepare
  5. 寫binlog
  6. 置redo log狀態為commit       

基於上述簡化版的undo log、redo log和binlog的寫入流程,我們來梳理下原子性、持久性、一致性的可靠性保證:

  A)假如是在步驟1/2/3中任一步驟發生故障,故障恢復後發現redo log中並無未完成的記錄,故障恢復後隻需要回滾undo log恢復現場即可;

  B)假如在步驟4/5中任一步驟發生故障,故障恢復後發現redo log處於prepare狀態,則進一步判斷是否已經寫入binlog:

  1. 若已經寫入binlog,則重新執行redo log的相關記錄直到成功達到commit狀態(主從的一致性);
  2. 若未寫入binlog,則回滾undo log恢復現場(原子性);       

  C)假如在步驟6發生故障,故障恢復後發現redo log處於commit狀態,表示過程全部正常完成,則什麼都不需要做。

總結

到此這篇關於Mysql中undo、redo與binlog區別的文章就介紹到這瞭,更多相關Mysql中undo、redo與binlog區別內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!

推薦閱讀: