目錄redo log介紹redo log整體流程redo log落盤(pán)策略redo log寫(xiě)入數(shù)據(jù)頁(yè)機(jī)制總結(jié)redo log介紹

redo log又叫“重做日志”,是存儲(chǔ)引擎層 (innoDB) 生成的日志，記錄的是"物理級(jí)別"上的頁(yè)修改操作，比如頁(yè)號(hào)x，偏移量y寫(xiě)入了'z'數(shù)據(jù)，主要目的為了保證數(shù)據(jù)不丟失，當(dāng)MySQL發(fā)生宕機(jī)的時(shí)候，可以利用redo log日志進(jìn)行數(shù)據(jù)恢復(fù)，如下圖所示。

默認(rèn)的redo log日志文件為ib_logfile0, ib_logfile1，如下圖：

那想過(guò)為什么要"多此一舉"先寫(xiě)入到redo log磁盤(pán)文件中，然后再落到數(shù)據(jù)庫(kù)表中？而不直接落到數(shù)據(jù)庫(kù)表中？

主要是因?yàn)轫樞騃O性能遠(yuǎn)高于隨機(jī)IO。

數(shù)據(jù)在MySQL中存儲(chǔ)是以頁(yè)為單位，事務(wù)中的數(shù)據(jù)可能遍布在不同的頁(yè)中，如果直接寫(xiě)入到對(duì)應(yīng)的頁(yè)中，是隨機(jī)IO寫(xiě)入。

而redo log是通過(guò)順序IO"追加"的方式寫(xiě)入到文件末尾，而且寫(xiě)入的內(nèi)容也是物理日志，比如比如，某個(gè)事務(wù)將系統(tǒng)表空間中第10號(hào)頁(yè)面中偏移量為 100 處的那個(gè)字節(jié)的值 1 改成 2等信息，日志占用空間也很小。

redo log整體流程

事務(wù)在寫(xiě)入到數(shù)據(jù)庫(kù)中涉及到redo log的整體流程如下圖所示：

性能不夠，緩存來(lái)湊。由于CPU的性能遠(yuǎn)遠(yuǎn)大于磁盤(pán)，為了消除這個(gè)鴻溝，引入了兩個(gè)緩存，Buffer Pool和redo log buffer。Buffer Pool用來(lái)存放各種操作，比如寫(xiě)入數(shù)據(jù)時(shí)，先寫(xiě)到內(nèi)存中，然后由后臺(tái)線(xiàn)程再刷寫(xiě)到磁盤(pán)。redo log buffer用來(lái)存放重做日志，后續(xù)刷到磁盤(pán)中。

先將原始數(shù)據(jù)從磁盤(pán)中讀入到Buffer Pool中修改Buffer Pool中的數(shù)據(jù)生成一條重做日志并寫(xiě)入redo log buffer，記錄數(shù)據(jù)修改后的值當(dāng)事務(wù)提交時(shí)，將redo log buffer中的內(nèi)容追加磁盤(pán)中的redo log文件中將磁盤(pán)日志文件redo log file 內(nèi)容刷到數(shù)據(jù)庫(kù)表中

上面流程中這種先寫(xiě)日志，再寫(xiě)磁盤(pán)，只有日志寫(xiě)入成功，才算事務(wù)提交成功的技術(shù)思想在MySQL也叫做WAL技術(shù) (Write-Ahead Logging)。

redo log落盤(pán)策略

事務(wù)的日志是先寫(xiě)入到redo log buffer 中是很快的，那如何保證redo log buffer中的信息高效的落到磁盤(pán)日志文件中呢？

redo log buffer不是直接將日志內(nèi)容刷盤(pán)到redo log file中。redo log buffer內(nèi)容先刷入到操作系統(tǒng)的文件系統(tǒng)緩存 （page cache）中去，這個(gè)過(guò)程很快，而且整個(gè)系統(tǒng)宕機(jī)概率相對(duì)MySQL會(huì)小很多。最后，日志內(nèi)容會(huì)從操作系統(tǒng)的文件系統(tǒng)緩存中刷到磁盤(pán)的日志文件中，至于什么時(shí)候觸發(fā)這個(gè)動(dòng)作，MySQL的innoDB引擎提供了3種策略可選。

InnoDB引擎提供了 innodb_flush_log_at_trx_commit 參數(shù)，該參數(shù)控制 commit提交事務(wù)時(shí)，如何將 redo log buffer 中的日志刷新到 redo log file 的3種策略。

innodb_flush_log_at_trx_commit=1

每次事務(wù)提交時(shí)都將進(jìn)行同步, 執(zhí)行主動(dòng)刷盤(pán)操作，如上圖的紅線(xiàn)位置，所以只要事務(wù)提交成功，redo log記錄就一定在硬盤(pán)里，不會(huì)有田可數(shù)據(jù)丟失。該種方式是MySQL innoDB存儲(chǔ)引擎默認(rèn)的刷盤(pán)機(jī)制。如果事務(wù)執(zhí)行期間MySQL掛了或宕機(jī)，這部分日志丟了，但是事務(wù)并沒(méi)有提交，所以日志丟了也不會(huì)有損

失?？梢员ＷCACID的D，數(shù)據(jù)絕對(duì)不會(huì)丟失，但是效率最差的。

innodb_flush_log_at_trx_commit=2

為2時(shí)，只要事務(wù)提交成功，redo log buffer中的內(nèi)容只寫(xiě)入文件系統(tǒng)緩存（pagecache）如果僅僅只是MySQL掛了不會(huì)有任何數(shù)據(jù)丟失，但是操作系統(tǒng)宕機(jī)可能會(huì)有1秒數(shù)據(jù)的丟失，這種情況下無(wú)法滿(mǎn)足ACID中的D數(shù)值2的效率是高于數(shù)值等于1的innodb_flush_log_at_trx_commit=0

為0時(shí)，后臺(tái)線(xiàn)程每隔1秒進(jìn)行一次重做日志的刷盤(pán)操作，因此MySQL掛了最多丟失1秒鐘內(nèi)的事務(wù)。這種方式效率是最高的，這種策略也有丟失數(shù)據(jù)的風(fēng)險(xiǎn)，也無(wú)法保證持久性。其他被動(dòng)觸發(fā)刷盤(pán)的場(chǎng)景

除了上面3種策略進(jìn)行刷盤(pán)以外，還有兩種場(chǎng)景會(huì)讓一個(gè)沒(méi)有提交的事務(wù)的 redo log 寫(xiě)入到磁盤(pán)中。

redo log buffer 占用的空間即將達(dá)到 innodb_log_buffer_size 一半的時(shí)候，后臺(tái)線(xiàn)程會(huì)主動(dòng)寫(xiě)盤(pán)。注意，由于這個(gè)事務(wù)并沒(méi)有提交，所以這個(gè)寫(xiě)盤(pán)動(dòng)作只是 write，而沒(méi)有調(diào)用 fsync，也就是只留在了文件系統(tǒng)的 page cache。并行的事務(wù)提交的時(shí)候，順帶將這個(gè)事務(wù)的 redo log buffer 持久化到磁盤(pán)。假設(shè)一個(gè)事務(wù) A 執(zhí)行到一半，已經(jīng)寫(xiě)了一些 redo log 到 buffer 中，這時(shí)候有另外一個(gè)線(xiàn)程的事務(wù) B 提交，如果 innodb_flush_log_at_trx_commit 設(shè)置的是 1，那么按照這個(gè)參數(shù)的邏輯，事務(wù) B 要把 redo log buffer 里的日志全部持久化到磁盤(pán)。這時(shí)候，就會(huì)帶上事務(wù) A 在 redo log buffer 里的日志一起持久化到磁盤(pán)。

小結(jié)：

我們可以根據(jù)實(shí)際的業(yè)務(wù)場(chǎng)景，在性能和持久性做一些權(quán)衡，但建議使用默認(rèn)值，雖然操作系統(tǒng)宕機(jī)的概率理論小于數(shù)據(jù)庫(kù)宕機(jī)的概率，但是一般既然使用了事務(wù)，那么數(shù)據(jù)的安全相對(duì)來(lái)說(shuō)更重要些。

redo log寫(xiě)入數(shù)據(jù)頁(yè)機(jī)制

目前事務(wù)日志已經(jīng)落入到磁盤(pán)的redo log file中了，MySQL會(huì)去讀取這個(gè)文件將數(shù)據(jù)寫(xiě)入到數(shù)據(jù)頁(yè)中。

很顯然，目前對(duì)redo log file會(huì)進(jìn)行讀和寫(xiě)的操作。在日志文件組中有兩個(gè)重要的“指針”，分別是 write pos、``checkpoint。

write pos是當(dāng)前記錄的位置，一邊寫(xiě)一邊后移checkpoint是當(dāng)前要擦除的位置，也是往后推移

每次刷盤(pán) redo log 記錄到日志文件組中，write pos 位置就會(huì)后移更新。每次MySQL加載日志文件組恢復(fù)數(shù)據(jù)時(shí)，會(huì)清空加載過(guò)的 redo log 記錄，并把checkpoint后移更新。如果write pos 追上 checkpoint ，表示日志文件組滿(mǎn)了，這時(shí)候不能再寫(xiě)入新的 redo log記錄，MySQL 得停下來(lái)，清空一些記錄，把 checkpoint 推進(jìn)一下，如下圖：

這就是整個(gè)redo log file中的日志恢復(fù)到數(shù)據(jù)頁(yè)中的過(guò)程。

總結(jié)

本文講解了事務(wù)日志redo log在MySQL innoDB存儲(chǔ)引擎工作的機(jī)制，它主要是用來(lái)保證事務(wù)的持久性，避免數(shù)據(jù)丟失。如果本文對(duì)你有幫助，請(qǐng)留下一個(gè)贊。

到此這篇關(guān)于詳解MySQL事務(wù)日志redo log的文章就介紹到這了,更多相關(guān)MySQL事務(wù)日志redo log內(nèi)容請(qǐng)搜索好吧啦網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持好吧啦網(wǎng)！