大家好。上篇文章我們介紹了什么是redo日志以及redo日志的寫(xiě)入過(guò)程。建議沒(méi)看過(guò)上篇文章的同學(xué)先看一下上一篇文章，今天我們繼續(xù)來(lái)說(shuō)一說(shuō)redo日志。

一、redo日志文件

1. redo日志刷盤(pán)時(shí)機(jī)

我們知道m(xù)tr運(yùn)行過(guò)程中產(chǎn)生的一組redo日志在mtr結(jié)束時(shí)會(huì)被復(fù)制到log buffer中，可是這些日志總在內(nèi)存里呆著也不是個(gè)辦法，在一些情況下它們會(huì)被刷新到磁盤(pán)里，比如：

• log buffer空間不足時(shí)：log buffer的大小是有限的（通過(guò)系統(tǒng)變量 innodb_log_buffer_size 指定），如果不停的往這個(gè)有限大小的log buffer 里塞入日志，很快它就會(huì)被填滿(mǎn)。InnoDB認(rèn)為如果當(dāng)前寫(xiě)入log buffer 的redo日志量已經(jīng)占滿(mǎn)了log buffer總?cè)萘康拇蠹s一半左右，就需要把這些日志刷新到磁盤(pán)上。
• 事務(wù)提交時(shí)：我們前邊說(shuō)過(guò)之所以使用redo日志主要是因?yàn)樗加玫目臻g少，還是順序?qū)懀谑聞?wù)提交時(shí)可以不把修改過(guò)的Buffer Pool頁(yè)面刷新到磁盤(pán)，但是為了保證持久性，必須要把修改這些頁(yè)面對(duì)應(yīng)的redo日志刷新到磁盤(pán)。
• 后臺(tái)線(xiàn)程不停的刷刷刷：后臺(tái)有一個(gè)線(xiàn)程，大約每秒都會(huì)刷新一次log buffer中的redo日志到磁盤(pán)。
• 正常關(guān)閉服務(wù)器時(shí)。
• 做所謂的checkpoint時(shí)（一會(huì)兒介紹過(guò)checkpoint的概念）
• 其他的一些情況…

2. redo日志文件組

MySQL的數(shù)據(jù)目錄（使用 SHOW VARIABLES LIKE ‘datadir’ 查看）下默認(rèn)有兩個(gè)名為ib_logfile0和ib_logfile1的文件， log buffer中的日志默認(rèn)情況下就是刷新到這兩個(gè)磁盤(pán)文件中。如果我們對(duì)默認(rèn)的 redo 日志文件不滿(mǎn)意，可以通過(guò)下邊幾個(gè)啟動(dòng)參數(shù)來(lái)調(diào)節(jié)：

innodb_log_group_home_dir

該參數(shù)指定了redo 日志文件所在的目錄，默認(rèn)值就是當(dāng)前的數(shù)據(jù)目錄。

innodb_log_file_size

該參數(shù)指定了每個(gè)redo日志文件的大小。

innodb_log_files_in_group

該參數(shù)指定redo日志文件的個(gè)數(shù)，默認(rèn)值為2，最大值為100。

從上邊的描述中可以看到，磁盤(pán)上的redo日志文件不只一個(gè)，而是以一個(gè)日志文件組的形式出現(xiàn)的。這些文件以ib_logfile[數(shù)字]的形式進(jìn)行命名。在將redo日志寫(xiě)入日志文件組時(shí)，是 從ib_logfile0開(kāi)始寫(xiě)，如果 ib_logfile0 寫(xiě)滿(mǎn)了，寫(xiě)入ib_logfile1中，依此類(lèi)推。如果寫(xiě)到最后一個(gè)文件，那就重新轉(zhuǎn)到ib_logfile0繼續(xù)寫(xiě)，所以整個(gè)過(guò)程如下圖所示：

總共的redo 日志文件大小其實(shí)就是：innodb_log_file_size × innodb_log_files_in_group。

3. redo日志文件格式

log buffer本質(zhì)上是一片連續(xù)的內(nèi)存空間，被劃分成了若干個(gè)512字節(jié)大小的block。將log buffer中的redo日志刷新到磁盤(pán)的本質(zhì)就是把block的鏡像寫(xiě)入日志文件中，所以redo日志文件其實(shí)也是由若干個(gè)512 字節(jié)大小的block組成。

redo日志文件組中的每個(gè)文件大小都一樣，格式也一樣，都是由兩部分組成：

• 前2048個(gè)字節(jié)，也就是前4個(gè)block是用來(lái)存儲(chǔ)一些管理信息的。
• 從第2048字節(jié)往后是用來(lái)存儲(chǔ)log buffer中的block鏡像的。

所以我們前邊所說(shuō)的循環(huán)使用redo日志文件，其實(shí)是從每個(gè)日志文件的第2048個(gè)字節(jié)開(kāi)始算，畫(huà)個(gè)示意圖就是這樣：

下面我們介紹一下每個(gè)redo日志文件前2048個(gè)字節(jié)，也就是前4個(gè)特殊block的格式都是干嘛的，廢話(huà)少說(shuō)，直接看圖：

從圖中可以看出來(lái)，這4個(gè)block分別是：

log file header： 描述該 redo 日志文件的一些整體屬性，看一下它的結(jié)構(gòu)：

各個(gè)屬性的具體釋義如下：

checkpoint1： 記錄關(guān)于 checkpoint 的一些屬性，結(jié)構(gòu)如下所示：

checkpoint1： 記錄關(guān)于 checkpoint 的一些屬性，結(jié)構(gòu)如下所示：

第三個(gè)block未使用，忽略～

checkpoint2： 結(jié)構(gòu)和checkpoint1一樣。

二、Log Sequeue Number

自mysql開(kāi)始運(yùn)行，就會(huì)不斷的生成redo日志。所以redo日志的量在不斷的遞增，永遠(yuǎn)不會(huì)縮減。Inno為記錄已經(jīng)寫(xiě)入的redo日志量，設(shè)計(jì)了一個(gè)稱(chēng)之為L(zhǎng)og Sequeue Number的全局變量–日志序列號(hào)，簡(jiǎn)稱(chēng) lsn 。InnoDB規(guī)定初始的lsn值為8704。

我們知道在向log buffer中寫(xiě)入redo日志時(shí)不是一條一條寫(xiě)入的，而是以一個(gè)mtr生成的一組redo日志為單位進(jìn)行寫(xiě)入的。而且實(shí)際上是把日志內(nèi)容寫(xiě)在了log block body處。但是在統(tǒng)計(jì)lsn的增長(zhǎng)量時(shí)，是按照實(shí)際 寫(xiě)入的日志量加上占用的log block header和log block trailer來(lái)計(jì)算的。我們來(lái)看一個(gè)例子：

系統(tǒng)第一次啟動(dòng)后初始化log buffer時(shí)， buf_free（就是標(biāo)記下一條 redo日志應(yīng)該寫(xiě)入到log buffer的位置的變量）就會(huì)指向第一個(gè)block的偏移量為12字節(jié)（log block header 的大小）的地方，那么 lsn 值也會(huì)跟著增加12：

如果某個(gè)mtr產(chǎn)生的一組redo日志占用的存儲(chǔ)空間比較小，也就是待插入的block剩余空閑空間能容納這個(gè)mtr提交的日志時(shí)，lsn增長(zhǎng)的量就是該mtr生成的redo日志占用的字節(jié)數(shù)，假設(shè)mtr_1產(chǎn)生的redo日志量為200字節(jié)，那么lsn就要在8716的基礎(chǔ)上增加200 ，變?yōu)?916 。就像這樣：

如果某個(gè)mtr產(chǎn)生的一組redo日志占用的存儲(chǔ)空間比較大，也就是待插入的block剩余空閑空間不足以容納這個(gè)mtr提交的日志時(shí)，lsn增長(zhǎng)的量就是該mtr 生成的redo日志占用的字節(jié)數(shù)加上額外占用的log block header和log block trailer的字節(jié)數(shù)，就像這樣：

所以：每一組由mtr生成的redo日志都有一個(gè)唯一的LSN值與其對(duì)應(yīng)，LSN值越小，說(shuō)明 redo日志產(chǎn)生的越早。

1. flushed_to_disk_lsn

redo日志是首先寫(xiě)到log buffer中，之后才會(huì)被刷新到磁盤(pán)上的redo 日志文件。所以InnoDB提出了一個(gè)稱(chēng)之為buf_next_to_write的全局變量，標(biāo)記當(dāng)前l(fā)og buffer中已經(jīng)有哪些日志被刷新到磁盤(pán)中了。畫(huà)個(gè)圖表示就是這樣：

我們前邊說(shuō)lsn 是表示當(dāng)前系統(tǒng)中寫(xiě)入的redo日志量，這包括了寫(xiě)到log buffer而沒(méi)有刷新到磁盤(pán)的日志， 相應(yīng)的，InnoDB提出了一個(gè)表示刷新到磁盤(pán)中的redo日志量的全局變量，稱(chēng)之為flushed_to_disk_lsn。
系統(tǒng)第一次啟動(dòng)時(shí)，該變量的值和初始的lsn值是相同的，都是 8704 。隨著系統(tǒng)的運(yùn)行，redo日志被不斷寫(xiě)入log buffer，但是并不會(huì)立即刷新到磁盤(pán)， lsn的值就和flushed_to_disk_lsn的值拉開(kāi)了差距。我們演示一下：
系統(tǒng)第一次啟動(dòng)后，向log buffer中寫(xiě)入了 mtr_1、mtr_2、mtr_3這三個(gè)mtr產(chǎn)生的redo日志，假設(shè)這三個(gè)mtr開(kāi)始和結(jié)束時(shí)對(duì)應(yīng)的lsn值分別是：

mtr_1：8716 ～ 8916。
mtr_2：8916 ～ 9948。
mtr_3：9948 ～ 10000。

此時(shí)的lsn 已經(jīng)增長(zhǎng)到了10000，但是由于沒(méi)有刷新操作，所以此時(shí)flushed_to_disk_lsn的值仍為 8704 ，如圖：

隨后進(jìn)行將log buffer中的block刷新到redo日志文件的操作，假設(shè)將 mtr_1和mtr_2的日志刷新到磁盤(pán)，那么flushed_to_disk_lsn就應(yīng)該增長(zhǎng) mtr_1和mtr_2寫(xiě)入的日志量，所以flushed_to_disk_lsn的值增長(zhǎng)到了9948，如圖：

綜上所述，當(dāng)有新的redo 日志寫(xiě)入到log buffer 時(shí)，首先lsn的值會(huì)增長(zhǎng)，但flushed_to_disk_lsn不變， 隨后隨著不斷有l(wèi)og buffer中的日志被刷新到磁盤(pán)上， flushed_to_disk_lsn的值也跟著增長(zhǎng)。如果兩者的值相同時(shí)，說(shuō)明log buffer中的所有redo日志都已經(jīng)刷新到磁盤(pán)中了。

2. lsn值和redo日志文件偏移量的對(duì)應(yīng)關(guān)系

因?yàn)閘sn的值是代表系統(tǒng)寫(xiě)入的redo日志量的一個(gè)總和，一個(gè)mtr中產(chǎn)生多少日志，lsn的值就增加多少，這樣 mtr 產(chǎn)生的日志寫(xiě)到磁盤(pán)中時(shí)，很容 易計(jì)算某一個(gè)lsn值在redo日志文件組中的偏移量，如圖：

初始時(shí)的LSN值是8704，對(duì)應(yīng)文件偏移量2048，之后每個(gè)mtr向磁盤(pán)中寫(xiě)入多少字節(jié)日志，lsn的值就增長(zhǎng)多少。

3. lsn值和redo日志文件偏移量的對(duì)應(yīng)關(guān)系

我們知道一個(gè)mtr代表一次對(duì)底層頁(yè)面的原子訪(fǎng)問(wèn)，在訪(fǎng)問(wèn)過(guò)程中可能會(huì)產(chǎn)生一組不可分割的redo日志，在mtr結(jié)束時(shí)，會(huì)把這一組redo日志寫(xiě)入到log buffer中。除此之外，在mtr結(jié)束時(shí)還要把在mtr執(zhí)行過(guò)程中可能修改過(guò)的頁(yè)面加入到Buffer Pool的flush鏈表。我們看一下圖：

當(dāng)?shù)谝淮涡薷哪硞€(gè)緩存在Buffer Pool中的頁(yè)面時(shí)，就會(huì)把這個(gè)頁(yè)面對(duì)應(yīng)的控制塊插入到flush鏈表的頭部，之后再修改該頁(yè)面時(shí)由于它已經(jīng)在flush鏈表中了，就不再次插入了。也就是說(shuō)flush鏈表中的臟頁(yè)是按照頁(yè)面的第一次修改時(shí)間從大到小進(jìn)行排序的。

在這個(gè)過(guò)程中會(huì)在緩存頁(yè)對(duì)應(yīng)的控制塊中記錄兩個(gè)關(guān)于頁(yè)面何時(shí)修改的屬性：

oldest_modification： 如果某個(gè)頁(yè)面被加載到Buffer Pool后進(jìn)行第一次修改，那么就將修改該頁(yè)面的mtr開(kāi)始時(shí)對(duì)應(yīng)的lsn值寫(xiě)入這個(gè)屬性。

newest_modification： 每修改一次頁(yè)面，都會(huì)將修改該頁(yè)面的mtr 結(jié)束時(shí)對(duì)應(yīng)的lsn值寫(xiě)入這個(gè)屬性。也就是說(shuō)該屬性表示頁(yè)面最近一次修改后對(duì)應(yīng)的系統(tǒng)lsn值。

我們接著上講的flushed_to_disk_lsn的例子看一下：

假設(shè)mtr_1執(zhí)行過(guò)程中修改了頁(yè)a ，那么在mtr_1執(zhí)行結(jié)束時(shí)，就會(huì)將頁(yè)a對(duì)應(yīng)的控制塊加入到flush鏈表的頭部。并且將mtr_1開(kāi)始時(shí)對(duì)應(yīng)的lsn ，也就是8716 寫(xiě)入頁(yè)a對(duì)應(yīng)的控制塊的oldest_modification屬性中，把 mtr_1結(jié)束時(shí)對(duì)應(yīng)的lsn，也就是8916寫(xiě)入頁(yè)a對(duì)應(yīng)的控制塊的 newest_modification屬性中。畫(huà)個(gè)圖表示一下（為了讓美觀(guān)一些，我們把 oldest_modification 縮寫(xiě) 成了o_m，把newest_modification 縮寫(xiě)成了 n_m）：

接著假設(shè)mtr_2執(zhí)行過(guò)程中又修改了頁(yè)b和頁(yè)c兩個(gè)頁(yè)面，那么在mtr_2執(zhí)行結(jié)束時(shí)，就會(huì)將頁(yè)b和頁(yè)c對(duì)應(yīng)的控制塊都加入到flush鏈表的頭部。并且將mtr_2開(kāi)始時(shí)對(duì)應(yīng)的lsn，也就是8916寫(xiě)入頁(yè)b和頁(yè)c對(duì)應(yīng)的控制塊的oldest_modification屬性中，把 mtr_2 結(jié)束時(shí)對(duì)應(yīng)的lsn，也就是9948寫(xiě)入頁(yè)b和頁(yè)c對(duì)應(yīng)的控制塊的newest_modification屬性中。畫(huà)個(gè)圖表示一下：

接著假設(shè)mtr_3執(zhí)行過(guò)程中修改了頁(yè)b和頁(yè)d，不過(guò)頁(yè)b之前已經(jīng)被修改過(guò)了，所以它對(duì)應(yīng)的控制塊已經(jīng)被插入到了flush鏈表，所以在mtr_3執(zhí)行結(jié)束時(shí)，只需要將頁(yè)d對(duì)應(yīng)的控制塊都加入到flush鏈表的頭部即可。所以需要將mtr_3開(kāi)始時(shí)對(duì)應(yīng)的lsn，也就是9948寫(xiě)入頁(yè)d對(duì)應(yīng)的控制塊的 oldest_modification屬性中，把 mtr_3結(jié)束時(shí)對(duì)應(yīng)的lsn，也就是10000寫(xiě)入頁(yè)d對(duì)應(yīng)的控制塊的newest_modification屬性中。另外，由于頁(yè)b在 mtr_3 執(zhí)行過(guò)程中又發(fā)生了一次修改，所以需要更新頁(yè) b對(duì)應(yīng)的控制塊中newest_modification的值為10000。畫(huà)個(gè)圖表示一下：

綜上所述，flush鏈表中的臟頁(yè)按照修改發(fā)生的時(shí)間順序進(jìn)行排序，也就是按照oldest_modification代表的LSN值進(jìn)行排序，被多次更新的頁(yè)面不會(huì)重復(fù)插入到flush鏈表中，但是會(huì)更新newest_modification屬性的值。

三、checkpoint

我們要考慮一件事，就是redo日志文件組容量是有限的，我們不得不選擇循環(huán)使用redo日志文件組中的文件，但是這會(huì)造成最后寫(xiě)的redo日志與最開(kāi)始寫(xiě)的redo日志追尾，這時(shí)應(yīng)該想到：redo日志只是為了系統(tǒng)崩潰后恢復(fù)臟頁(yè)用的，如果對(duì)應(yīng)的臟頁(yè)已經(jīng)刷新到了磁盤(pán)，也就是說(shuō)即使現(xiàn)在系統(tǒng)崩潰，那么在重啟后也用不著使用redo日志恢復(fù)該頁(yè)面了，所以該redo日志也就沒(méi)有存在的必要了，那么它占用的磁盤(pán)空間就可以被后續(xù)的 redo日志所重用。也就是說(shuō)：判斷某些redo日志占用的磁盤(pán)空間是否可以覆蓋的依據(jù)就是它對(duì)應(yīng)的臟頁(yè)是否已經(jīng)刷新到磁盤(pán)里。我們看一下前邊一直說(shuō)的那個(gè)例子：

如圖，雖然mtr_1和mtr_2生成的redo日志都已經(jīng)被寫(xiě)到了磁盤(pán)上，但是它們修改的臟頁(yè)仍然留在Buffer Pool中，所以它們生成的redo日志在磁盤(pán)上的空間是不可以被覆蓋的。之后隨著系統(tǒng)的運(yùn)行，如果頁(yè)a被刷新到了磁盤(pán)，那么它對(duì)應(yīng)的控制塊就會(huì)從flush鏈表中移除，就像這樣子：

這樣mtr_1生成的redo日志就沒(méi)有用了，它們占用的磁盤(pán)空間就可以被覆蓋掉了。InnoDB提出了 一個(gè)全局變量checkpoint_lsn來(lái)代表當(dāng)前系統(tǒng)中可以被覆蓋的redo日志總量是多少，這個(gè)變量初始值也是8704 。比方說(shuō)現(xiàn)在頁(yè)a被刷新到了磁盤(pán)，mtr_1生成的redo日志就可以被覆蓋了，所以我們可以進(jìn)行一個(gè)增加checkpoint_lsn的操作，我們把這個(gè)過(guò)程稱(chēng)之為做一次 checkpoint 。做一次 checkpoint 其實(shí)可以分為兩個(gè)步驟：

步驟一：計(jì)算一下當(dāng)前系統(tǒng)中可以被覆蓋的redo日志對(duì)應(yīng)的lsn值最大是多少。redo 日志可以被覆蓋，意味著它對(duì)應(yīng)的臟頁(yè)被刷到了磁盤(pán)，只要我們計(jì)算出當(dāng)前系統(tǒng)中被最早修改的臟頁(yè)對(duì)應(yīng)的oldest_modification 值，那凡是在系統(tǒng)lsn值小于該節(jié)點(diǎn)的oldest_modification值時(shí)產(chǎn)生的redo日志都是可以被覆蓋掉的，我們就把該臟頁(yè)的oldest_modification 賦值給 checkpoint_lsn 。

比方說(shuō)當(dāng)前系統(tǒng)中頁(yè)a已經(jīng)被刷新到磁盤(pán)，那么flush鏈表的尾節(jié)點(diǎn)就是頁(yè)c，該節(jié)點(diǎn)就是當(dāng)前系統(tǒng)中最早修改的臟頁(yè)了，它的oldest_modification值為8916，我們就把8916賦值給checkpoint_lsn。

步驟二：將checkpoint_lsn 和對(duì)應(yīng)的redo日志文件組偏移量以及此次 checkpint 的編號(hào)寫(xiě)到日志文件的管理信息（就是checkpoint1 或者 checkpoint2 ）中。InnoDB維護(hù)了一個(gè)目前系統(tǒng)做了多少次checkpoint 的變量 checkpoint_no，每做一次 checkpoint，該變量的值就加1。我們前邊說(shuō)過(guò)計(jì)算一個(gè)lsn值對(duì)應(yīng)的redo日志文件組偏移量是很容易的，所以可以計(jì)算得到該checkpoint_lsn在redo日志文件組中對(duì)應(yīng)的偏移量 checkpoint_offset ，然后 把這三個(gè)值都寫(xiě)到redo 日志文件組的管理信息中。

每一個(gè)redo日志文件都有2048 個(gè)字節(jié)的管理信息，但是上述關(guān)于checkpoint的信息只會(huì)被寫(xiě)到日志文件組的第一個(gè)日志文件的管理信息中。不過(guò)我們是存儲(chǔ)到checkpoint1中還是checkpoint2中呢？InnoDB 規(guī)定，當(dāng)checkpoint_no的值是偶數(shù)時(shí)，就寫(xiě)到checkpoint1中，是奇數(shù)時(shí)，就寫(xiě)到checkpoint2中。記錄完checkpoint的信息之后， redo日志文件組中各個(gè)lsn值的關(guān)系就像這樣：

四、 用戶(hù)線(xiàn)程批量從flush鏈表中刷出臟頁(yè)

一般情況下都是后臺(tái)的線(xiàn)程在對(duì)LRU鏈表和flush鏈表進(jìn)行刷臟操作， 這主要因?yàn)樗⑴K操作比較慢，不想影響用戶(hù)線(xiàn)程處理請(qǐng)求。但是如果當(dāng)前系統(tǒng)修改頁(yè)面的操作十分頻繁，這樣就導(dǎo)致寫(xiě)日志操作十分頻繁，系統(tǒng)lsn值增長(zhǎng)過(guò)快。如果后臺(tái)的刷臟操作不能將臟頁(yè)刷出，那么系統(tǒng)無(wú)法及時(shí)做 checkpoint ，可能就需要用戶(hù)線(xiàn)程同步的從flush鏈表中把那些最早修改的臟頁(yè)（ oldest_modification最小的臟頁(yè)）刷新到磁盤(pán)，這樣這些臟頁(yè)對(duì)應(yīng)的redo日志就沒(méi)用了，然后就可以去做checkpoint了。

五、 查看系統(tǒng)中的各種LSN值

我們可以使用SHOW ENGINE INNODB STATUS命令查看當(dāng)前 InnoDB存儲(chǔ)引擎中的各種LSN值的情況，比如：

mysql> SHOW ENGINE INNODB STATUS\G 
(...省略前邊的許多狀態(tài)) 
LOG --- 
Log sequence number 124476971 
Log flushed up to   124099769 
Pages flushed up to 124052503 
Last checkpoint at  124052494 
0 pending log flushes, 0 pending chkp writes 
24 log i/o's done, 2.00 log i/o's/second ---------------------- 
(...省略后邊的許多狀態(tài))

Log sequence number： 代表系統(tǒng)中的 lsn 值，也就是當(dāng)前系統(tǒng)已經(jīng)寫(xiě)入的redo日志量，包括寫(xiě)入log buffer中的日志。
Log flushed up to： 代表flushed_to_disk_lsn的值，也就是當(dāng)前系統(tǒng)已經(jīng)寫(xiě)入磁盤(pán)的redo日志量。
Pages flushed up to： 代表 flush鏈表中被最早修改的那個(gè)頁(yè)面對(duì)應(yīng)的oldest_modification屬性值。
Last checkpoint at： 當(dāng)前系統(tǒng)的checkpoint_lsn值。

六、 innodb_flush_log_at_trx_commit的用法

為了保證事務(wù)的持久性，用戶(hù)線(xiàn)程在事務(wù)提交時(shí)需要將該事務(wù)執(zhí)行過(guò)程中產(chǎn)生的所有redo日志都刷新到磁盤(pán)上。這一條要求太狠了，會(huì)很明顯的降低數(shù)據(jù)庫(kù)性能。如果對(duì)事務(wù)的持久性要求不是那么強(qiáng)烈的話(huà)，可以選擇修改一個(gè)稱(chēng)為innodb_flush_log_at_trx_commit的系統(tǒng)變量的值，該變量有3個(gè)可選的值：

0 ： 當(dāng)該系統(tǒng)變量值為0時(shí)，表示在事務(wù)提交時(shí)不立即向磁盤(pán)中同步redo日志，這個(gè)任務(wù)是交給后臺(tái)線(xiàn)程 做的。這樣很明顯會(huì)加快請(qǐng)求處理速度，但是如果事務(wù)提交后服務(wù)器掛了，后臺(tái)線(xiàn)程沒(méi)有及時(shí)將redo日志刷新到 磁盤(pán)，那么該事務(wù)對(duì)頁(yè)面的修改會(huì)丟失。

1 ： 當(dāng)該系統(tǒng)變量值為1時(shí)，表示在事務(wù)提交時(shí)需要將redo日志同步到磁盤(pán)，可以保證事務(wù)的持久性。1也是innodb_flush_log_at_trx_commit 的默認(rèn)值。

2 ： 當(dāng)該系統(tǒng)變量值為2時(shí)，表示在事務(wù)提交時(shí)需要將redo日志寫(xiě)到操作系統(tǒng)的緩沖區(qū)中，但并不需要保 證將日志真正的刷新到磁盤(pán)。這種情況下如果數(shù)據(jù)庫(kù)掛了，操作系統(tǒng)沒(méi)掛的話(huà)，事務(wù)的持久性還是可以保證的，但是操作系統(tǒng)也掛了的話(huà)，那就不能保證持久性了。

七、崩潰恢復(fù)

在服務(wù)器不掛的情況下，redo日志不僅沒(méi)用，反而讓性能變得更差。但是當(dāng)數(shù)據(jù)庫(kù)掛了，我們就可以在重啟時(shí)根據(jù)redo日志中的記錄就可以將頁(yè)面恢復(fù)到系統(tǒng)崩潰前的狀態(tài)。我們接下來(lái)大致看一下恢復(fù)過(guò)程。

1. 確定恢復(fù)的起點(diǎn)

checkpoint_lsn之前的redo日志都可以被覆蓋，也就是說(shuō)這些 redo 日志對(duì)應(yīng)的臟頁(yè)都已經(jīng)被刷新到磁盤(pán)中了，既然它們已經(jīng)被刷盤(pán)，我們就沒(méi)必要恢復(fù)它們了。對(duì)于checkpoint_lsn之后的redo日志，它們對(duì)應(yīng)的臟頁(yè)可能沒(méi)被刷盤(pán)，也可能被刷盤(pán)了，我們不能確定，所以需要從checkpoint_lsn開(kāi)始讀取redo日志來(lái)恢復(fù)頁(yè)面。

當(dāng)然，redo 日志文件組的第一個(gè)文件的管理信息中有兩個(gè)block都存儲(chǔ)了checkpoint_lsn的信息，我們當(dāng)然是要選取最近發(fā)生的那次checkpoint的信息。衡量checkpoint發(fā)生時(shí)間早晚的信息就是所謂的 checkpoint_no， 我們只要把checkpoint1和checkpoint2這兩個(gè)block中的 checkpoint_no值讀出來(lái)比一下大小，哪個(gè)checkpoint_no值更大，說(shuō)明哪個(gè)block存儲(chǔ)的就是最近的一次checkpoint信息。這樣我們就能拿到最近發(fā)生的checkpoint 對(duì)應(yīng)的checkpoint_lsn值以及它在 redo 日志文件組中的偏移量checkpoint_offset。

2. 確定恢復(fù)的終點(diǎn)

redo日志恢復(fù)的起點(diǎn)確定了，那終點(diǎn)是哪個(gè)呢？這個(gè)還得從block的結(jié)構(gòu)說(shuō)起。我們說(shuō)在寫(xiě)redo日志的時(shí)候都是順序?qū)懙?，?xiě)滿(mǎn)了一個(gè)block之后會(huì)再往下一個(gè)block中寫(xiě)：

普通block的 log block header部分有一個(gè)稱(chēng)之為 LOG_BLOCK_HDR_DATA_LEN的屬性，該屬性值記錄了當(dāng)前block里使用了多少字節(jié)的空間。對(duì)于被填滿(mǎn)的block來(lái)說(shuō)，該值永遠(yuǎn)為512 。如果該屬性的值不為512，那么它就是此次崩潰恢復(fù)中需要掃描的最后一個(gè)block。

3. 怎么恢復(fù)

確定了需要掃描哪些redo 日志進(jìn)行崩潰恢復(fù)之后，接下來(lái)就是怎么進(jìn)行恢復(fù)了。假設(shè)現(xiàn)在的redo日志文件中有5條redo日志，如圖：

由于redo 0在checkpoint_lsn后邊，恢復(fù)時(shí)可以不管它。我們現(xiàn)在可以按照redo日志的順序依次掃描checkpoint_lsn之后的各條redo日志，按照日志中記載的內(nèi)容將對(duì)應(yīng)的頁(yè)面恢復(fù)出來(lái)。這樣沒(méi)什么問(wèn)題，不過(guò)InnoDB還是想了一些辦法加快這個(gè)恢復(fù)的過(guò)程：

使用哈希表： 根據(jù)redo日志的space ID和page number屬性計(jì)算出散列值，把space ID和page number相同的redo日志放到哈希表的同一個(gè)槽里，如果有多個(gè)space ID和page number都相同的redo日志，那么它們之間使用鏈表連接起來(lái)，按照生成的先后順序鏈接起來(lái)的，如圖所示：

之后就可以遍歷哈希表，因?yàn)閷?duì)同一個(gè)頁(yè)面進(jìn)行修改的redo日志都放在了一個(gè)槽里，所以可以一次性將一個(gè)頁(yè)面修復(fù)好，這樣可以加快恢復(fù)速度。

另外需要注意一點(diǎn)的是，同一個(gè)頁(yè)面的redo日志是按照生成時(shí)間順序進(jìn)行排序的，所以恢復(fù)的時(shí)候也是按照這個(gè)順序進(jìn)行恢復(fù)，如果不按照生成時(shí)間順序進(jìn)行排序的話(huà)，那么可能出現(xiàn)錯(cuò)誤。比如原先的修改操作是先插入一條記錄，再刪除該條記錄，如果恢復(fù)時(shí)不按照這個(gè)順序來(lái)，就可能變成先刪除一條記錄，再插入一條記錄，這顯然是錯(cuò)誤的。

跳過(guò)已經(jīng)刷新到磁盤(pán)的頁(yè)面： checkpoint_lsn之前的redo日志對(duì)應(yīng)的臟頁(yè)確定都已經(jīng)刷到磁盤(pán)了，但是 checkpoint_lsn之后的redo日志我們不能確定是否已經(jīng)刷到磁盤(pán)，主要是因?yàn)樵谧罱龅囊淮蝐heckpoint后，可能后臺(tái)線(xiàn)程又不斷的從LRU鏈表和flush鏈表中將一些臟頁(yè)刷出Buffer Pool 。這些 在checkpoint_lsn之后的redo日志，如果它們對(duì)應(yīng)的臟頁(yè)在崩潰發(fā)生時(shí)已經(jīng)刷新到磁盤(pán)，那在恢復(fù)時(shí)也就沒(méi)有必要根據(jù)redo 日志的內(nèi)容修改該頁(yè)面了。

那在恢復(fù)時(shí)怎么知道某個(gè)redo日志對(duì)應(yīng)的臟頁(yè)是否在崩潰發(fā)生時(shí)已經(jīng)刷新到磁盤(pán)了呢？這還得從頁(yè)面的結(jié)構(gòu)說(shuō)起，我們知道每個(gè)頁(yè)面都有一個(gè)稱(chēng)之為File Header的部分，在File Header里有一個(gè)稱(chēng)之為 FIL_PAGE_LSN的屬性，該屬性記載了最近一次修改頁(yè)面時(shí)對(duì)應(yīng)的lsn值（其實(shí)就是頁(yè)面控制塊中的newest_modification值）。如果在做了某次 checkpoint之后有臟頁(yè)被刷新到磁盤(pán)中，那么該頁(yè)對(duì)應(yīng)的FIL_PAGE_LSN 代表的lsn值肯定大于checkpoint_lsn的值，凡是符合這種情況的頁(yè)面就不需要重復(fù)執(zhí)行 lsn值小于 FIL_PAGE_LSN 的redo日志了，所以更進(jìn)一步提升了崩潰恢復(fù)的速度。

八、 遺漏的問(wèn)題：LOG_BLOCK_HDR_NO是如何計(jì)算的

我們前邊說(shuō)過(guò)，對(duì)于實(shí)際存儲(chǔ)redo日志的普通的log block來(lái)說(shuō)，在 log block header處有一個(gè)稱(chēng)之為L(zhǎng)OG_BLOCK_HDR_NO的屬性，我們說(shuō)這個(gè)屬性代表一個(gè)唯一的標(biāo)號(hào)。這個(gè)屬性是初次使用該block時(shí)分配的，跟當(dāng)時(shí)的系統(tǒng)lsn值有關(guān)。使用下邊的公式計(jì)算該block的 LOG_BLOCK_HDR_NO值：

((lsn / 512) & 0x3FFFFFFFUL) + 1

這個(gè)公式里的0x3FFFFFFFUL可能讓大家有點(diǎn)困惑，其實(shí)它的二進(jìn)制表示可能更親切一點(diǎn)：

從圖中可以看出，0x3FFFFFFFUL對(duì)應(yīng)的二進(jìn)制數(shù)的前2位為0，后30位的值都為1 。一個(gè)二進(jìn)制位與0做與運(yùn)算（&）的結(jié)果肯定是0，一個(gè)二進(jìn)制位與1做與運(yùn)算（&）的結(jié)果就是原值。讓一個(gè)數(shù)和0x3FFFFFFFUL 做與運(yùn)算的意思就是要將該值的前2個(gè)比特位的值置為0，這樣該值就肯定小于或等于 0x3FFFFFFFUL了。

這也就說(shuō)明了，不論lsn多大， ((lsn / 512) & 0x3FFFFFFFUL) 的值肯定在0到0x3FFFFFFFUL之間，再加1的話(huà)肯定在1到0x40000000UL之間。而0x40000000UL這個(gè)值就代表著1GB。也就是說(shuō)系統(tǒng)最多能產(chǎn)生不重復(fù)的LOG_BLOCK_HDR_NO值只有1GB個(gè)。InnoDB規(guī)定redo日志文件組中包含的所有文件大小總和不得超過(guò)512GB，一個(gè)block大小是512字節(jié)，也就是說(shuō)redo日志文件組中包含的block塊最多為1GB個(gè)，所以有1GB個(gè)不重復(fù)的編號(hào)值也就夠用了。

另外，LOG_BLOCK_HDR_NO值的第一個(gè)比特位比較特殊，稱(chēng)之為 flush bit，如果該值為1，代表著本block是在某次將log buffer中的block刷新到磁盤(pán)的操作中的第一個(gè)被刷入的block。

到此這篇關(guān)于mysql中 redo日志的文章就介紹到這了,更多相關(guān)mysql redo日志內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！