詳解MySQL中事務的持久性實現原理

前言

說到數據庫事務,大傢腦子裡一定很容易蹦出一堆事務的相關知識,如事務的ACID特性,隔離級別,解決的問題(臟讀,不可重復讀,幻讀)等等,但是可能很少有人真正的清楚事務的這些特性又是怎麼實現的,為什麼要有四個隔離級別。

在之前的文章我們已經瞭解瞭MySQL中事務的隔離性的實現原理,今天就繼續來聊一聊MySQL持久性的實現原理。

當然MySQL博大精深,文章疏漏之處在所難免,歡迎批評指正。

說明

MySQL的事務實現邏輯是位於引擎層的,並且不是所有的引擎都支持事務的,下面的說明都是以InnoDB引擎為基準。

InnoDB讀寫數據原理

在往下學習之前,我們需要先來瞭解下InnoDB是怎麼來讀寫數據的。我們知道數據庫的數據都是存放在磁盤中的,然後我們也知道磁盤I/O的成本是很大的,如果每次讀寫數據都要訪問磁盤,數據庫的效率就會非常低。為瞭解決這個問題,InnoDB提供瞭 Buffer Pool 作為訪問數據庫數據的緩沖。

Buffer Pool 是位於內存的,包含瞭磁盤中部分數據頁的映射。當需要讀取數據時,InnoDB會首先嘗試從Buffer Pool中讀取,讀取不到的話就會從磁盤讀取後放入Buffer Pool;當寫入數據時,會先寫入Buffer Pool的頁面,並把這樣的頁面標記為dirty,並放到專門的flush list上,這些修改的數據頁會在後續某個時刻被刷新到磁盤中(這一過程稱為刷臟,由其他後臺線程負責) 。如下圖所示:

這樣設計的好處是可以把大量的磁盤I/O轉成內存讀寫,並且把對一個頁面的多次修改merge成一次I/O操作(刷臟一次刷入整個頁面),避免每次讀寫操作都訪問磁盤,從而大大提升瞭數據庫的性能。

持久性定義

持久性是指事務一旦提交,它對數據庫的改變就應該是永久性的,接下來的其他操作或故障不應該對本次事務的修改有任何影響。

通過前面的介紹,我們知道InnoDB使用 Buffer Pool  來提高讀寫的性能。但是 Buffer Pool 是在內存的,是易失性的,如果一個事務提交瞭事務後,MySQL突然宕機,且此時Buffer Pool中修改的數據還沒有刷新到磁盤中的話,就會導致數據的丟失,事務的持久性就無法保證。

為瞭解決這個問題,InnoDB引入瞭 redo log來實現數據修改的持久化。當數據修改時,InnoDB除瞭修改Buffer Pool中的數據,還會在redo log 記錄這次操作,並保證redo log早於對應的頁面落盤(一般在事務提交的時候),也就是常說的WAL。若MySQL突然宕機瞭且還沒有把數據刷回磁盤,重啟後,MySQL會通過已經寫入磁盤的redo log來恢復沒有被刷新到磁盤的數據頁。

實現原理:redo log

為瞭提高性能,和數據頁類似,redo log 也包括兩部分:一是內存中的日志緩沖(redo log buffer),該部分日志是易失性的;二是磁盤上的重做日志文件(redo log file),該部分日志是持久的。redo log是物理日志,記錄的是數據庫中物理頁的情況 。

當數據發生修改時,InnoDB不僅會修改Buffer Pool中的數據,也會在redo log buffer記錄這次操作;當事務提交時,會對redo log buffer進行刷盤,記錄到redo log file中。如果MySQL宕機,重啟時可以讀取redo log file中的數據,對數據庫進行恢復。這樣就不需要每次提交事務都實時進行刷臟瞭。

寫入過程

註意點:

  • 先修改Buffer Pool,後寫 redo log buffer。
  • redo日志比數據頁先寫回磁盤:事務提交的時候,會把redo log buffer寫入redo log file,寫入成功才算提交成功(也有其他場景觸發寫入,這裡就不展開瞭),而Buffer Pool的數據由後臺線程在後續某個時刻寫入磁盤。
  • 刷臟的時候一定會保證對應的redo log已經落盤瞭,也即是所謂的WAL(預寫式日志),否則會有數據丟失的可能性。

好處

事務提交的時候,寫入redo log 相比於直接刷臟的好處主要有三點:

刷臟是隨機I/O,但寫redo log 是順序I/O,順序I/O可比隨機I/O快多瞭,不需要。
刷臟是以數據頁(Page)為單位的,即使一個Page隻有一點點修改也要整頁寫入;而redo log中隻包含真正被修改的部分,數據量非常小,無效IO大大減少。
刷臟的時候可能要刷很多頁的數據,無法保證原子性(例如隻寫瞭一部分數據就失敗瞭),而redo log buffer 向 redo log file 寫log block,是按512個字節,也就是一個扇區的大小進行寫入,扇區是寫入的最小單位,因此可以保證寫入是必定成功的。

先寫redo log還是先修改數據

一次DML可能涉及到數據的修改和redo log的記錄,那它們的執行順序是怎麼樣的呢?網上的文章有的說先修改數據,後記錄redo log,有的說先記錄redo log,後改數據,那真實的情況是如何呢?

首先通過上面的說明我們知道,redo log buffer在事務提交的時候就會寫入redo log file的,而刷臟則是在後續的某個時刻,所以可以確定的是先記錄redo log,後修改data page(WAL當然是日志先寫啦)。

那接下來的問題就是先寫redo log buffer還是先修改Buffer Pool瞭。要瞭解這個問題,我們先要瞭解InnoDB中,一次DML的執行過程是怎麼樣的。一次DML的執行過程涉及瞭數據的修改,加鎖,解鎖,redo log的記錄和undo log的記錄等,也是需要保證原子性的,而InnoDB通過MTR(Mini-transactions)來保證一次DML操作的原子性。

首先來看MTR的定義:

 An internal phase of InnoDB processing, when making changes at the physical level to internal data structures during DML operations. A Mini-transactions (mtr) has no notion of rollback; multiple Mini-transactionss can occur within a single transaction. Mini-transactionss write information to the redo log that is used during crash recovery. A Mini-transactions can also happen outside the context of a regular transaction, for example during purge processing by background threads. 見 https://dev.mysql.com/doc/refman/8.0/en/glossary.html

MTR 是一個短原子操作,不能回滾,因為它本身就是原子的。數據頁的變更必須通過MTR,MTR 會把DML操作對數據頁的修改記錄到 redo log裡。

下面來簡單看下MTR的過程:

  • MTR初始化的時候會初始化一份 mtr_buf
  • 當修改數據時,在對內存Buffer Pool中的頁面進行修改的同時,還會生成redo log record,保存在mtr_buf中。
  • 在執行mtr_commit函數提交本MTR的時候,會將mtr_buf中的redo log record更新到redo log buffer中,同時將臟頁添加到flush list,供後續刷臟使用。在log buffer中,每接收到496字節的log record,就將這組log record包裝一個12字節的block header和一個4字節的block tailer,成為一個512字節的log block,方便刷盤的時候對齊512字節刷盤。

由此可見,InnoDB是先修改Buffer Pool,後寫redo log buffer的。

恢復數據的過程

在任何情況下,InnoDB啟動時都會嘗試執行recovery操作。在恢復過程中,需要redo log參與,而如果還開啟瞭binlog,那就還需要binlog、undo log的參與。因為有可能數據已經寫入binlog瞭,但是redo log還沒有刷盤的時候數據庫就奔潰瞭(事務是InnoDB引擎的特性,修改瞭數據不一定提交瞭,而binlog是MySQL服務層的特性,修改數據就會記錄瞭),這時候就需要redo log,binlog和undo log三者的參與來判斷是否有還沒提交的事務,未提交的事務進行回滾或者提交操作。

下面來簡單說下僅利用redo log恢復數據的過程:

  • 啟動InnoDB時,找到最近一次Checkpoint的位置,利用Checkpoint LSN去找大於該LSN的redo log進行日志恢復。
  • 如果中間恢復失敗瞭也沒影響,再次恢復的時候還是從上次保存成功的Checkpoint的位置繼續恢復。

Recover過程:故障恢復包含三個階段:Analysis,Redo和Undo。Analysis階段的任務主要是利用Checkpoint及Log中的信息確認後續Redo和Undo階段的操作范圍,通過Log修正Checkpoint中記錄的Dirty Page集合信息,並用其中涉及最小的LSN位置作為下一步Redo的開始位置RedoLSN。同時修正Checkpoint中記錄的活躍事務集合(未提交事務),作為Undo過程的回滾對象;Redo階段從Analysis獲得的RedoLSN出發,重放所有的Log中的Redo內容,註意這裡也包含瞭未Commit事務;最後Undo階段對所有未提交事務利用Undo信息進行回滾,通過Log的PrevLSN可以順序找到事務所有需要回滾的修改。具體見 http://catkang.github.io/2019/01/16/crash-recovery.html

什麼是LSN?

LSN也就是log sequence number,也日志的序列號,是一個單調遞增的64位無符號整數。redo log和數據頁都保存著LSN,可以用作數據恢復的依據。LSN更大的表示所引用的日志記錄所描述的變化發生在更後面。

什麼是Checkpoint?

Checkpoint表示一個保存點,在這個點之前的數據頁的修改(log LSN<Checkpoint LSN)都已經寫入磁盤文件瞭。InnoDB每次刷盤之後都會記錄Checkpoint,把最新的redo log LSN 記錄到Checkpoint LSN 裡,方便恢復數據的時候作為起始點的判斷。

以上就是詳解MySQL中事務的持久性實現原理的詳細內容,更多關於MySQL 事務的持久性的資料請關註WalkonNet其它相關文章!