MySQL InnoDB Update和Crash Recovery流程詳解
1.2.3 什么是Log Sequence Number （LSN）？
一個64位無符號整數(shù)，表示Redo Log系統(tǒng)中的時間點，也是事務(wù)寫入Redo Log的字節(jié)總量，從日志初始化開始計數(shù)（數(shù)據(jù)庫初始化安裝時間點開始且單調(diào)遞增）
LSN不僅存在于Redo Log中，在每個數(shù)據(jù)頁中都保存著一個LSN，在進行數(shù)據(jù)恢復(fù)時通過LSN做比較運算可以判斷出每個數(shù)據(jù)頁是否需要進行恢復(fù)操作
1.2.4 什么是Checkpoint？
一個時間點，由一個LSN值（Checkpoint LSN）表示的整型值，在Checkpoint LSN之前的每個數(shù)據(jù)頁（buffer pool中的臟頁）的更改都已經(jīng)落盤（刷新到數(shù)據(jù)文件中），Checkpoint 完成后，在Checkpoint LSN之前的Redo Log就不再需要了。
Checkpoint技術(shù)是為了解決：全量Redo Log恢復(fù)時間太長、buffer pool中的空閑頁不夠用時將臟頁刷新到磁盤數(shù)據(jù)文件、Redo Log空間不夠用時將臟頁刷新到磁盤數(shù)據(jù)文件等問題。
Checkpoint方式有兩種：Sharp Checkpoint和Fuzzy Checkpoint（又可根據(jù)不同的場景細(xì)分）
Sharp Checkpoint：將所有的臟頁刷回磁盤，數(shù)據(jù)庫實例關(guān)閉時系統(tǒng)參數(shù)innodb_fast_shutdown設(shè)置為0，才需要把所有的臟頁都刷回磁盤，刷臟時系統(tǒng)hang住
Fuzzy Checkpoint：持續(xù)的每次只刷新一部分臟頁到磁盤，數(shù)據(jù)庫正常運行過程中都是使用這種方式刷臟，在InnoDB內(nèi)部還可細(xì)分為如下幾種：
Master線程每秒/每十秒固定執(zhí)行Checkpoint
LRU list中空閑頁不夠時，觸發(fā)Checkpoint從LRU list刷新臟頁以釋放足夠的空閑頁
Redo Log空間不夠時，觸發(fā)Checkpoint從Flush list刷新臟頁，Checkpoint執(zhí)行完成之后，在這個位置之前的Redo Log不再需要（即，可以循環(huán)覆蓋使用）
臟頁太多達(dá)到臟頁比例閥值（系統(tǒng)參數(shù)innodb_max_dirty_pages_pct和innodb_max_dirty_pages_pct_lwm控制臟頁比例閥值），觸發(fā)Checkpoint
1.2.5 什么是Rollback Pointer （ROLL_PTR）？
一個由rollback segment number、page number和page offset組成的指針，指向Undo Log中包含之前版本數(shù)據(jù)的具體Undo Log日志記錄。
可用于為任何數(shù)據(jù)記錄回退到一個歷史版本記錄、可用于mvcc中重建舊版本記錄、可用于事務(wù)回滾。
1.2.6 什么是Transaction ID （TRX_ID）？
表示事務(wù)開始點的一個64位無符號整數(shù)
每個事務(wù)的事務(wù)號增量增加
事務(wù)號會寫入聚簇索引的每個記錄中
最大事務(wù)號會寫入系統(tǒng)表空間的TRX_SYS頁
1.2.7 什么是Transaction Serialization Number（TRX_NO） ？
一個64位無符號整數(shù)，表示事務(wù)提交時的最大TRX_ID
TRX_NO在事務(wù)提交時會寫入Undo Log Header
TRX_NO可用于purge Undo Log中的舊版本記錄
2. Update流程2.1 事務(wù)start（事務(wù)首次開啟）
為這個事務(wù)分配事務(wù)ID（TRX_ID），該事務(wù)ID可能被寫入系統(tǒng)表空間的TRX_SYS頁面中的最大的事務(wù)ID字段（Transaction ID）
* 如果系統(tǒng)表空間的TRX_SYS頁面中的最大的事務(wù)ID字段被更新，則該更新會被記錄到Redo Log中。
根據(jù)分配的TRX_ID創(chuàng)建read view。
2.2 記錄修改（每次只修改一行記錄）
分配Undo Log日志空間
拷貝該記錄修改之前的值到Undo Log中
將Undo Log的修改記錄寫入Redo Log中
在buffer pool中修改數(shù)據(jù)頁，回滾段指針指向Undo Log中該記錄之前的版本
將該記錄對應(yīng)的數(shù)據(jù)頁變更部分寫入Undo Log中
buffer pool中該記錄修改之后的數(shù)據(jù)頁被標(biāo)記為”臟頁”（需要刷新到磁盤的數(shù)據(jù)頁）
2.3 此時其他事務(wù)的修改會怎樣？
一旦記錄被修改，即使沒有提交，其他事務(wù)也可能會看到被修改后的記錄，這依賴于他們的事務(wù)隔離級別而定：
如果是RU隔離級別，則使用索引頁讀取最新版本記錄
如果是RU隔離級別，則查找記錄的最新提交版本
如果是RR隔離級別，則查找與其read view相對應(yīng)的記錄版本
任何需要使用索引頁來讀取比最新的版本記錄舊的版本記錄時，都必須使用Undo Log來重建之前的版本記錄。
2.4 事務(wù)提交（顯式和隱式提交）
事務(wù)對應(yīng)的Undo Log頁被設(shè)置為”purge”（意味著當(dāng)這個Undo Log頁不再被任何其他事務(wù)引用時可以將其清除）
將Undo Log的修改記錄寫入Redo Log中
Redo Log Buffer刷新到磁盤（是否刷盤取決于系統(tǒng)變量innodb_flush_log_at_trx_commit的設(shè)置）
2.5 后臺線程刷臟（后臺線程連續(xù)不斷地根據(jù)不同觸發(fā)機制觸發(fā)刷新）
查找最舊的“臟”頁面（修改時間最早的頁面）并將其添加到flush batch中
確保在flush batch中中最新的LSN號已經(jīng)寫入到了Redo Log中且已經(jīng)落盤
如果開啟了雙寫，則先將臟頁刷新到雙寫緩沖區(qū)（并等待同步）
將每個臟頁從buffer pool中寫入最終目的地：表空間文件中的
PS：對于后臺線程刷臟部分，執(zhí)行刷新臟頁時，與該臟頁的事務(wù)是否提交無關(guān)，只需要確保該頁對應(yīng)LSN號的Redo Log記錄落盤，而不會去判斷事務(wù)的狀態(tài)是否是提交還是未提交狀態(tài)，因為，數(shù)據(jù)頁結(jié)構(gòu)中并沒有地方單獨記錄事務(wù)的狀態(tài)（即，無法判斷事務(wù)是否提交），只是在每行數(shù)據(jù)中有記錄事務(wù)號、回滾段指針（所以一個頁中也可能包含多個事務(wù)的修改記錄）。當(dāng)需要對某個事務(wù)進行回滾時，重新從表空間中讀取這個未提交的臟頁，使用undo log中的反向數(shù)據(jù)進行反向修改，然后再重新刷臟。
2.6 定期執(zhí)行Checkpoint
確保比Checkpoint 點更舊（比Checkpoint LSN小）的臟頁已刷新到表空間文件，如果存在有比Checkpoint LSN大的臟頁，則立即刷新臟頁到數(shù)據(jù)文件中。說白了Checkpoint機制主要作用就是用于刷新臟頁。
把Checkpoint LSN寫到Redo Log Header中 （從這個Checkpoint LSN開始，之前的Redo Log記錄不再需要）。
2.7 后臺線程Purge（后臺線程連續(xù)不斷地根據(jù)需要定期執(zhí)行Purge，包括Undo Log和歷史鏈表）
查找每個回滾段中不再需要的最舊的Undo Log
實際上是從索引中刪除任何帶有刪除標(biāo)記的記錄
釋放Undo Log頁
修剪history lists
3. Creash Recovery流程3.1 什么時候會進行Crash Recovery？
實例崩潰之后重啟
使用一個備份還原（如：LVM 快照、xtrabackup備份）后
在“快速”（innodb_fast_shutdown不為0值關(guān)閉實例）關(guān)閉實例后重新啟動
3.2 檢測實例是不是干凈地關(guān)閉的
打開Redo Logs和系統(tǒng)表空間文件（ibdataN）
讀取并從中找到最大的Checkpoint LSN
從最近的Checkpoint 開始往后掃描Redo Log
如果能夠找到Redo Log記錄，說明還有數(shù)據(jù)頁的更改沒有刷新到數(shù)據(jù)文件上，啟動Crash Recovery，使用Redo Log來恢復(fù)數(shù)據(jù)的一致性
3.3 使用所有獨立表空間的表名和表空間ID創(chuàng)建一個名稱到ID的映射
打開datadir下的所有.ibd文件
在這些表空間文件的offset 0的頁（FSP_HDR頁）頭讀取其表空間ID（FSP_HDR頁中FSP Header的前四個字節(jié)記錄著表空間ID）
將表空間ID與表名建立映射
非常好我支持^.^
(1) 100%
不好我反對
(0) 0%