詳解MySQL中事務的持久性實現(xiàn)原理

前言

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

在之前的文章我們已經(jīng)了解了MySQL中事務的隔離性的實現(xiàn)原理，今天就繼續(xù)來聊一聊MySQL持久性的實現(xiàn)原理。

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

說明

MySQL的事務實現(xiàn)邏輯是位于引擎層的，并且不是所有的引擎都支持事務的，下面的說明都是以InnoDB引擎為基準。

InnoDB讀寫數(shù)據(jù)原理

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

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

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

持久性定義

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

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

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

實現(xiàn)原理：redo log

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

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

寫入過程

注意點：

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

好處

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

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

先寫redo log還是先修改數(shù)據(jù)

一次DML可能涉及到數(shù)據(jù)的修改和redo log的記錄，那它們的執(zhí)行順序是怎么樣的呢？網(wǎng)上的文章有的說先修改數(shù)據(jù)，后記錄redo log，有的說先記錄redo log，后改數(shù)據(jù)，那真實的情況是如何呢？

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

那接下來的問題就是先寫redo log buffer還是先修改Buffer Pool了。要了解這個問題，我們先要了解InnoDB中，一次DML的執(zhí)行過程是怎么樣的。一次DML的執(zhí)行過程涉及了數(shù)據(jù)的修改，加鎖，解鎖，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 是一個短原子操作，不能回滾，因為它本身就是原子的。數(shù)據(jù)頁的變更必須通過MTR，MTR 會把DML操作對數(shù)據(jù)頁的修改記錄到 redo log里。

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

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

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

恢復數(shù)據(jù)的過程

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

下面來簡單說下僅利用redo log恢復數(shù)據(jù)的過程：

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

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

什么是LSN?

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

什么是Checkpoint？

Checkpoint表示一個保存點，在這個點之前的數(shù)據(jù)頁的修改（log LSNCheckpoint LSN）都已經(jīng)寫入磁盤文件了。InnoDB每次刷盤之后都會記錄Checkpoint，把最新的redo log LSN 記錄到Checkpoint LSN 里，方便恢復數(shù)據(jù)的時候作為起始點的判斷。

以上就是詳解MySQL中事務的持久性實現(xiàn)原理的詳細內容，更多關于MySQL 事務的持久性的資料請關注腳本之家其它相關文章！