MySQL中事務(wù)持久性的實(shí)現(xiàn)原理是什么

MySQL中事務(wù)持久性的實(shí)現(xiàn)原理是什么？相信很多沒有經(jīng)驗(yàn)的人對(duì)此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個(gè)問題。

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

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

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

持久性定義

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

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

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

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

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

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

寫入過程

注意點(diǎn)：

• 先修改Buffer Pool，后寫 redo log buffer。

• redo日志比數(shù)據(jù)頁先寫回磁盤：事務(wù)提交的時(shí)候，會(huì)把redo log buffer寫入redo log file，寫入成功才算提交成功（也有其他場(chǎng)景觸發(fā)寫入，這里就不展開了），而Buffer Pool的數(shù)據(jù)由后臺(tái)線程在后續(xù)某個(gè)時(shí)刻寫入磁盤。

• 刷臟的時(shí)候一定會(huì)保證對(duì)應(yīng)的redo log已經(jīng)落盤了，也即是所謂的WAL（預(yù)寫式日志），否則會(huì)有數(shù)據(jù)丟失的可能性。
  

好處

事務(wù)提交的時(shí)候，寫入redo log 相比于直接刷臟的好處主要有三點(diǎn)：

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

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

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

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

那接下來的問題就是先寫redo log buffer還是先修改Buffer Pool了。要了解這個(gè)問題，我們先要了解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 是一個(gè)短原子操作，不能回滾，因?yàn)樗旧砭褪窃拥?。?shù)據(jù)頁的變更必須通過MTR，MTR 會(huì)把DML操作對(duì)數(shù)據(jù)頁的修改記錄到 redo log里。

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

• MTR初始化的時(shí)候會(huì)初始化一份 mtr_buf

• 當(dāng)修改數(shù)據(jù)時(shí)，在對(duì)內(nèi)存Buffer Pool中的頁面進(jìn)行修改的同時(shí)，還會(huì)生成redo log record，保存在mtr_buf中。

• 在執(zhí)行mtr_commit函數(shù)提交本MTR的時(shí)候，會(huì)將mtr_buf中的redo log record更新到redo log buffer中，同時(shí)將臟頁添加到flush list，供后續(xù)刷臟使用。在log buffer中，每接收到496字節(jié)的log record，就將這組log record包裝一個(gè)12字節(jié)的block header和一個(gè)4字節(jié)的block tailer，成為一個(gè)512字節(jié)的log block，方便刷盤的時(shí)候?qū)R512字節(jié)刷盤。
  

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

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

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

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

• 啟動(dòng)InnoDB時(shí)，找到最近一次Checkpoint的位置，利用Checkpoint LSN去找大于該LSN的redo log進(jìn)行日志恢復(fù)。

• 如果中間恢復(fù)失敗了也沒影響，再次恢復(fù)的時(shí)候還是從上次保存成功的Checkpoint的位置繼續(xù)恢復(fù)。
  

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

什么是LSN?

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

什么是Checkpoint？

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

看完上述內(nèi)容，你們掌握MySQL中事務(wù)持久性的實(shí)現(xiàn)原理是什么的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！