下文內(nèi)容主要給大家?guī)韗edo日志進(jìn)行MySQL的Crash Recovey（崩潰恢復(fù)）解析，這里所講到的知識，與書籍略有不同，都是創(chuàng)新互聯(lián)專業(yè)技術(shù)人員在與用戶接觸過程中，總結(jié)出來的，具有一定的經(jīng)驗分享價值，希望給廣大讀者帶來幫助。

創(chuàng)新互聯(lián)成立與2013年，公司以成都網(wǎng)站設(shè)計、網(wǎng)站制作、系統(tǒng)開發(fā)、網(wǎng)絡(luò)推廣、文化傳媒、企業(yè)宣傳、平面廣告設(shè)計等為主要業(yè)務(wù)，適用行業(yè)近百種。服務(wù)企業(yè)客戶成百上千，涉及國內(nèi)多個省份客戶。擁有多年網(wǎng)站建設(shè)開發(fā)經(jīng)驗。為企業(yè)提供專業(yè)的網(wǎng)站建設(shè)、創(chuàng)意設(shè)計、宣傳推廣等服務(wù)。 通過專業(yè)的設(shè)計、獨特的風(fēng)格，為不同客戶提供各種風(fēng)格的特色服務(wù)。

MySQL的InnoDB存儲引引擎的物理文件存儲體系中，除了實際的數(shù)據(jù)文件(ibd, ibdata)之外，還有兩個非常重要的日志系統(tǒng)，分別是redo日志和undo日志。 跟Oracle類似， redo log記錄了對實際數(shù)據(jù)文件的物理變更(數(shù)據(jù)文件的什么位置數(shù)據(jù)做了如何的變更)。InnoDB也是采用了WAL(日志優(yōu)先落盤)，也就是說在實際數(shù)據(jù)文件的修改落盤之前redo日志已經(jīng)落盤，從而來保證事務(wù)的持久性。Undo日志用來保證事務(wù)的原子性和MVCC，所有的undo操作產(chǎn)身的數(shù)據(jù)文件的變更也會記錄到redo日志中。
在原生的MySQL中，redo日志不會用來做物理主從復(fù)制，其主要的應(yīng)用場景是用來進(jìn)行MySQL的Crash Recovey（崩潰恢復(fù)）。關(guān)于MySQL InnoDB的崩潰恢復(fù)會在后續(xù)的文章中進(jìn)行介紹。

本文主要基于MySQL 8.0介紹redo Log的基本構(gòu)成。
1.    redo 日志文件
從MySQL 5.6開始，已經(jīng)廢棄了日志組的特性（redo日志可以寫多份），網(wǎng)上有觀點認(rèn)為可能是InnoDB的開發(fā)團(tuán)隊認(rèn)為用外層的存儲硬件來保證日志組的完整性可能更好一些。同時從5.7開始InnoDB的歸檔日志Archive也被放棄(歸檔日志用來歸檔存放所有的redo日志，redo日志系統(tǒng)內(nèi)是采用固定尺寸的多個log文件循環(huán)寫的方式來存放redo日志，如果寫滿了會循環(huán)到開始的位置開始寫入)。
不過MySQL 8.0引入一個稱之為克隆的機(jī)制，從代碼的角度來看，似乎是用來實現(xiàn)遠(yuǎn)程克隆一個當(dāng)前數(shù)據(jù)庫的副本，在這個機(jī)制中又引入的新的Archive歸檔機(jī)制。如果讀者有興趣可以閱讀一下MySQL8.0新版本源碼的storage\innobase\arch和 storage\innobase\clone目錄下的代碼。
1.1.  redo Log相關(guān)參數(shù)
innodb_log_group_home_dir
該參數(shù)用來指定redo日志存放的路徑，日志文件以ib_logfile[number]來命名。
innodb_log_files_in_group
雖然MySQL已經(jīng)放棄了日志組的概念，但參數(shù)名依舊保留了下來以兼容以前的配置。該參數(shù)的含義為有多少個log文件(最少為2個)。
innodb_log_file_size
表示每個文件的大小。
所以，總的redo Log的大小為 innodb_log_files_in_group * innodb_log_file_size.

1.2.  redo Log循環(huán)寫
redo Log以順序的方式寫入文件，當(dāng)全部文件寫滿的時候則回到第一個文件相應(yīng)的起始位置進(jìn)行覆蓋寫（但在做redo checkpoint時，也會更新第一個日志文件的頭部checkpoint標(biāo)記，所以嚴(yán)格來講也不算順序?qū)懀?，在InnoDB內(nèi)部，邏輯上Redo Log被看作一個文件，對應(yīng)一個space id (InnoDB通過space的概念來組織物理存儲，包括不同的表，數(shù)據(jù)字典，redo，undo等)。

上圖是以指定innodb_log_files_in_group為3的循環(huán)寫的情況。

2.    Redo Log存儲格式簡介
盡管Redo Log有多個文件，但每個文件的組成結(jié)構(gòu)是一樣的，只是有一些數(shù)據(jù)只會存在的第一個Log文件(ib_logfile0)的文件頭中, 例如Buffer Pool flush checkpoint信息只會寫在第一個log文件的文件頭中。
2.1.  日志文件存儲結(jié)構(gòu)概覽

(ib_logfile0 存儲概覽圖)

(ib_logfile0 之外其它redo log文件的存儲概覽)
InnoDB也是采用WAL的機(jī)制來保證事務(wù)的持久性，從一定的意義上來說，redo日志是順序?qū)?，寫入速度很快。?shù)據(jù)庫事務(wù)導(dǎo)致的數(shù)據(jù)修改進(jìn)入到InnoDB存儲層之后會將這些修改變更的記錄存入redo log中，然后將數(shù)據(jù)的變更寫入內(nèi)存中的Page Pool中。InnoDB的后臺線程會按照一定的規(guī)則(例如定時或者臟頁的數(shù)量達(dá)到一定的比例)將臟頁落盤，落盤后會記錄下來當(dāng)前redo Log中有多少變更日志已經(jīng)實際存儲到了實際的數(shù)據(jù)space文件中。redo log的總的寫入量叫LSN（Log Secquence Numer）日志序列號，這個redo log變更實際寫入到實際數(shù)據(jù)文件中的數(shù)量叫checkpoint LSN，表示的是有多少變更已經(jīng)實際寫入到了相應(yīng)的數(shù)據(jù)文件中。 一旦數(shù)據(jù)庫崩潰InnoDB開始恢復(fù)數(shù)據(jù)的時候，先讀取checkpoint，然后從checkpoint所指示的LSN讀取其之后的Redo日志進(jìn)行數(shù)據(jù)恢復(fù)，從而減少Crash Recovery的時間。
比較前面兩個概覽圖可以看到，checkpoint信息只是存儲在第一個log文件頭中。同時我們看到日志頭中有2個checkpoint block域。InnoDB是采用2個checkpoint了輪流寫的方式來保證checkpoint的安全（并不是一次寫2份checkpoint, 而是輪流寫）。 也由于Redo log是冪等的，應(yīng)用一次和與應(yīng)用兩次都是一樣的(在實際的應(yīng)用Redo中，如果當(dāng)前這一條log的lsn大于當(dāng)前page的lsn,說明這一條log還沒有被應(yīng)用到當(dāng)前page中去)。所以，即使某次checkpoint block寫失敗了，那么崩潰恢復(fù)的時候從上一次記錄的checkpoint點開始恢復(fù)也能正確的恢復(fù)數(shù)據(jù)庫事務(wù)。
2.2.  Log File Header

（Log File Header存儲結(jié)構(gòu)）
Log Header Format:
這個字段以前用來標(biāo)識當(dāng)前Log文件屬于哪個日志組，現(xiàn)在新的意義是用來標(biāo)識當(dāng)前Log為文件的格式版本。例如如果為0則表示這個redo log是有5.7.9以前的MySQL生成的。
PAD:
沒有任何含義，目前僅僅用來做一些對齊處理。
Start LSN:
這個字段用在Clone和Archive場景，與一般的持久性、崩潰恢復(fù)無關(guān)，這里不做討論。
Creator:
存儲的是創(chuàng)建這個log文件創(chuàng)建者的名稱的字符串。
Left Bytes:
目前沒有任何含義，僅僅是用來填充占位，以便讓這個block達(dá)到512字節(jié)大小。
2.3.  Log Checkpoint

(Checkpoint block儲存概覽)
checkpoint number:
checkpoint number可以理解為checkpoint域?qū)懕P的次數(shù)，每次寫盤遞增1，同時這個值取模2可以實現(xiàn)2個checkpoint域輪流寫。
checkpoint LSN：
該字段標(biāo)示小于這個Checkpoint LSN的日志記錄都已經(jīng)寫入到了實際的數(shù)據(jù)文件中，Crash Recovery系統(tǒng)從Checkpoint LSN之后的第一個MTR記錄開始進(jìn)行數(shù)據(jù)恢復(fù)。
checkpoint offset：
Checkpoint LSN對應(yīng)在Log files中的文件偏移量，這個用來對LSN和Offset之間轉(zhuǎn)換進(jìn)行校準(zhǔn)。
Buf size:
MySQL系統(tǒng)內(nèi)只對該字段執(zhí)行了寫入，并為進(jìn)行讀取然后進(jìn)行相應(yīng)的處理。它標(biāo)識的是系統(tǒng)當(dāng)前Log buffer的大小。
Left bytes:
目前沒有任何含義，僅僅是用來填充占位，以便讓這個block達(dá)到512字節(jié)大小。但在這里最后4個字節(jié)用來存放該checkpoint域的Checksum。

2.4.  Log Block的存儲格式

(Log Block的存儲格式)
Log Block Number:
Log Block的編號，從1開始遞增，達(dá)到最大值(0x3FFFFFFF+1)后再繼續(xù)從1開始。
Data length:
寫入到當(dāng)前block的字節(jié)數(shù)，包含頭部12字節(jié)的大小
Firsrt Record offset
本Block內(nèi)第一個mtr記錄的起始偏移量
log Block Checkpoint number
該block所處在的checkpoint no
Log Records:
一個block內(nèi)可以存儲多條mtr記錄，同樣一個mtr記錄可以跨越多個block.
2.5.  redo日志邏輯格式到物理格式的映射

上圖是以指定innodb_log_files_in_group為2邏輯結(jié)構(gòu)到物理結(jié)構(gòu)的映射

上圖中上層的為Redolog的邏輯結(jié)構(gòu)，可以看作是內(nèi)存中的log buffer, 下層的為redo Log的實際物理文件存儲，由于版面的關(guān)系，我們以innodb_log_files_in_group為2來做示例，每個log文件中僅僅包含了2個log block(Log block的多少取決與設(shè)定的innodb_log_file_size)。
每產(chǎn)生一個mtr記錄就將其append到log buffer中去，當(dāng)log buffer落盤的時候會獲取固定大小的數(shù)據(jù)寫入到block的數(shù)據(jù)域。當(dāng)然，如果buffer中剩余的數(shù)據(jù)不足以填滿一個block的數(shù)據(jù)域，也會將其寫入到一個新的block中，不足的數(shù)據(jù)自動不齊，block header中的data length字段會指出有效數(shù)據(jù)的數(shù)量。

2.6.  MTR簡介
MTR即Mini-transaction的縮寫，字面意思小事物，相對邏輯事物而言，我們把它稱作物理事物。屬于Innodb存儲引擎的底層模塊。主要用于鎖和日志信息。InnoDB內(nèi)部的上層模塊會將事務(wù)操作轉(zhuǎn)換成若干的MTR物理事務(wù)。至于上層的事務(wù)操作如何轉(zhuǎn)換的MTR此操作，后續(xù)再另外單獨介紹，本文只介紹一下MTR記錄的格式。
每一個MTR操作會產(chǎn)身一條MTR Record, 下一小節(jié)我們會介紹一下MTR記錄的格式。
2.7.  MTR記錄格式
用一句通俗的話來講，一條MTR記錄表示的是對哪個數(shù)據(jù)文件(space id)的哪一頁(page)的頁內(nèi)某個偏移量(offset)位置做了什么改變(value).

(一條MTR記錄的通用格式)
Type:
MTR記錄的類型
Space ID:
該MTR記錄修改了哪個數(shù)據(jù)文件
Page Number
該MTR記錄修改了哪一頁
Record Payload:
根據(jù)Type的不同，Payload內(nèi)容格式也不相同，大小也不相同。后面會給出一個Type為MLOG_COMP_REC_INSERT大致的存儲結(jié)構(gòu)。
（MTR Type - MLOG_COMP_REC_INSERT）

最后列出一些MTR Record Type, 讀者從名字應(yīng)該就能看出這個Type的含義
/ one byte is written */
MLOG_1BYTE = 1,
/* 2 bytes ... /
MLOG_2BYTES = 2,
/4 bytes ... */
MLOG_4BYTES = 4,
/ 8 bytes ... */
MLOG_8BYTES = 8,
/* Record insert /
MLOG_REC_INSERT = 9,
/Mark clustered index record deleted */
MLOG_REC_CLUST_DELETE_MARK = 10,
/ Mark secondary index record deleted */
MLOG_REC_SEC_DELETE_MARK = 11,
/* update of a record, preserves record field sizes /
MLOG_REC_UPDATE_IN_PLACE = 13,
/!< Delete a record from a page /
MLOG_REC_DELETE = 14,
/Delete record list end on index page */
MLOG_LIST_END_DELETE = 15,
/ Delete record list start on index page */
MLOG_LIST_START_DELETE = 16,
/* Copy record list end to a new created index page /
MLOG_LIST_END_COPY_CREATED = 17,
/Reorganize an index page in ROW_FORMAT=REDUNDANT */
MLOG_PAGE_REORGANIZE = 18,
/ Create an index page */
MLOG_PAGE_CREATE = 19,
/* mark a compact index record as the predefined minimum record /
MLOG_COMP_REC_MIN_MARK = 36,
/create a compact index page */
MLOG_COMP_PAGE_CREATE = 37,
/* compact record insert /
MLOG_COMP_REC_INSERT = 38,
/* mark compact clustered index record deleted /
MLOG_COMP_REC_CLUST_DELETE_MARK = 39,

對于以上關(guān)于redo日志進(jìn)行MySQL的Crash Recovey（崩潰恢復(fù)）解析，如果大家還有更多需要了解的可以持續(xù)關(guān)注我們創(chuàng)新互聯(lián)的行業(yè)推新，如需獲取專業(yè)解答，可在官網(wǎng)聯(lián)系售前售后的，希望該文章可給大家?guī)硪欢ǖ闹R更新。