前言

InnoDB 有兩塊非常重要的日誌，一個是undo log，另外一個是redo log，前者用來保證事務的原子性以及InnoDB的MVCC，後者用來保證事務的持久性。

和大多數關系型數據庫一樣，InnoDB記錄了對數據文件的物理更改，並保證總是日誌先行，也就是所謂的WAL，即在持久化數據文件前，保證之前的redo日誌已經寫到磁盤。

LSN(log sequence number) 用於記錄日誌序號，它是一個不斷遞增的 unsigned long long 類型整數。在 InnoDB 的日誌系統中，LSN 無處不在，它既用於表示修改臟頁時的日誌序號，也用於記錄checkpoint，通過LSN，可以具體的定位到其在redo log文件中的位置。

為了管理臟頁，在 Buffer Pool 的每個instance上都維持了一個flush list，flush list 上的 page 按照修改這些 page 的LSN號進行排序。因此定期做redo checkpoint點時，選擇的 LSN 總是所有 bp instance 的 flush list 上最老的那個page（擁有最小的LSN）。由於采用WAL的策略，每次事務提交時需要持久化 redo log 才能保證事務不丟。而延遲刷臟頁則起到了合並多次修改的效果，避免頻繁寫數據文件造成的性能問題。

由於 InnoDB 日誌組的特性已經被廢棄（redo日誌寫多份），歸檔日誌(InnoDB archive log)特性也在5.7被徹底移除，本文在描述相關邏輯時會忽略這些邏輯。另外限於篇幅，InnoDB崩潰恢復的邏輯將在下期講述，本文重點闡述redo log 產生的生命周期以及MySQL 5.7的一些改進點。

本文的分析基於最新的MySQL 5.7.7-RC版本。

InnoDB 日誌文件

InnoDB的redo log可以通過參數innodb_log_files_in_group配置成多個文件，另外一個參數innodb_log_file_size表示每個文件的大小。因此總的redo log大小為innodb_log_files_in_group * innodb_log_file_size。

Redo log文件以ib_logfile[number]命名，日誌目錄可以通過參數innodb_log_group_home_dir控制。Redo log 以順序的方式寫入文件文件，寫滿時則回溯到第一個文件，進行覆蓋寫。（但在做redo checkpoint時，也會更新第一個日誌文件的頭部checkpoint標記，所以嚴格來講也不算順序寫）。

在InnoDB內部，邏輯上ib_logfile被當成了一個文件，對應同一個space id。由於是使用512字節block對齊寫入文件，可以很方便的根據全局維護的LSN號計算出要寫入到哪一個文件以及對應的偏移量。

Redo log文件是循環寫入的，在覆蓋寫之前，總是要保證對應的臟頁已經刷到了磁盤。在非常大的負載下，Redo log可能產生的速度非常快，導致頻繁的刷臟操作，進而導致性能下降，通常在未做checkpoint的日誌超過文件總大小的76%之後，InnoDB 認為這可能是個不安全的點，會強制的preflush臟頁，導致大量用戶線程stall住。如果可預期會有這樣的場景，我們建議調大redo log文件的大小。可以做一次幹凈的shutdown，然後修改Redo log配置，重啟實例。

除了redo log文件外，InnoDB還有其他的日誌文件，例如為了保證truncate操作而產生的中間日誌文件，包括 truncate innodb 表以及truncate undo log tablespace，都會產生一個中間文件，來標識這些操作是成功還是失敗，如果truncate沒有完成，則需要在 crash recovery 時進行重做。有意思的是，根據官方worklog的描述，最初實現truncate操作的原子化時是通過增加新的redo log類型來實現的，但後來不知道為什麽又改成了采用日誌文件的方式，也許是考慮到低版本兼容的問題吧。

關鍵結構體

log_sys對象

log_sys是InnoDB日誌系統的中樞及核心對象，控制著日誌的拷貝、寫入、checkpoint等核心功能。它同時也是大寫入負載場景下的熱點模塊，是連接InnoDB日誌文件及log buffer的樞紐，對應結構體為log_t。

其中與 redo log 文件相關的成員變量包括：

上述幾個sync/async點的計算方式可以參閱函數log_calc_max_ages，以如下實例配置為例：

innodb_log_files_in_group=4
innodb_log_file_size=4G
總文件大小: 17179869184

各個成員變量值及占總文件大小的比例：

log_sys->log_group_capacity = 15461874893 (90%)

log_sys->max_modified_age_async = 12175607164 (71%)

log_sys->max_modified_age_sync = 13045293390 (76%)

log_sys->max_checkpoint_age_async = 13480136503 (78%)

log_sys->max_checkpoint_age = 13914979615 (81%)

通常的：

當當前未刷臟的最老lsn和當前lsn的距離超過max_modified_age_async（71%）時，且開啟了選項innodb_adaptive_flushing時，page cleaner線程會去嘗試做更多的dirty page flush工作，避免臟頁堆積。 當當前未刷臟的最老lsn和當前Lsn的距離超過max_modified_age_sync(76%)時，用戶線程需要去做同步刷臟，這是一個性能下降的臨界點，會極大的影響整體吞吐量和響應時間。 當上次checkpoint的lsn和當前lsn超過max_checkpoint_age(81%)，用戶線程需要同步地做一次checkpoint，需要等待checkpoint寫入完成。 當上次checkpoint的lsn和當前lsn的距離超過max_checkpoint_age_async（78%）但小於max_checkpoint_age（81%）時，用戶線程做一次異步checkpoint（後臺異步線程執行CHECKPOINT信息寫入操作），無需等待checkpoint完成。

log_group_t結構體主要成員如下表所示：

與redo log 內存緩沖區相關的成員變量包括：

和Checkpoint檢查點相關的成員變量：

其他狀態變量

log_sys與日誌文件和日誌緩沖區的關系可用下圖來表示：

Mini transaction

Mini transaction(簡稱mtr)是InnoDB對物理數據文件操作的最小事務單元，用於管理對Page加鎖、修改、釋放、以及日誌提交到公共buffer等工作。一個mtr操作必須是原子的，一個事務可以包含多個mtr。每個mtr完成後需要將本地產生的日誌拷貝到公共緩沖區，將修改的臟頁放到flush list上。

mtr事務對應的類為mtr_t, mtr_t::Impl中保存了當前mtr的相關信息，包括:

在修改或讀一個數據文件中的數據時，一般是通過mtr來控制對對應page或者索引樹的加鎖，在5.7中，有以下幾種鎖類型（mtr_memo_type_t）：

mtr log生成

InnoDB的redo log都是通過mtr產生的，先寫到mtr的cache中，然後再提交到公共buffer中，本小節以INSERT一條記錄對page產生的修改為例，闡述一個mtr的典型生命周期。

入口函數：row_ins_clust_index_entry_low

開啟mtr

執行如下代碼塊

mtr_start(&mtr);
mtr.set_named_space(index->space);

mtr_start主要包括：

1. 初始化mtr的各個狀態變量

2. 默認模式為MTR_LOG_ALL，表示記錄所有的數據變更

3. mtr狀態設置為ACTIVE狀態（MTR_STATE_ACTIVE）

4. 為鎖管理對象和日誌管理對象初始化內存（mtr_buf_t）,初始化對象鏈表

mtr.set_named_space 是5.7新增的邏輯，將當前修改的表空間對象fil_space_t保存下來：如果是系統表空間，則賦值給m_impl.m_sys_space, 否則賦值給m_impl.m_user_space。

Tips： 在5.7裏針對臨時表做了優化，直接關閉redo記錄： mtr.set_log_mode(MTR_LOG_NO_REDO)

定位記錄插入的位置

主要入口函數： btr_cur_search_to_nth_level

不管插入還是更新操作，都是先以樂觀方式進行，因此先加索引S鎖 mtr_s_lock(dict_index_get_lock(index),&mtr)，對應mtr_t::s_lock函數 如果以悲觀方式插入記錄，意味著可能產生索引分裂，在5.7之前會加索引X鎖，而5.7版本則會加SX鎖（但某些情況下也會退化成X鎖） 加X鎖： mtr_x_lock(dict_index_get_lock(index), mtr),對應mtr_t::x_lock函數 加SX鎖：mtr_sx_lock(dict_index_get_lock(index),mtr)，對應mtr_t::sx_lock函數

對應到內部實現，實際上就是加上對應的鎖對象，然後將該鎖的指針和類型構建的mtr_memo_slot_t對象插入到mtr.m_impl.m_memo中。

當找到預插入page對應的block，還需要加block鎖，並把對應的鎖類型加入到mtr：mtr_memo_push(mtr, block, fix_type)

如果對page加的是MTR_MEMO_PAGE_X_FIX或者MTR_MEMO_PAGE_SX_FIX鎖，並且當前block是clean的，則將m_impl.m_made_dirty設置成true，表示即將修改一個幹凈的page。

如果加鎖類型為MTR_MEMO_BUF_FIX，實際上是不加鎖對象的，但需要判斷臨時表的場景，臨時表page的修改不加latch，但需要將m_impl.m_made_dirty設置為true（根據block的成員m_impl.m_made_dirty來判斷），這也是5.7對InnoDB臨時表場景的一種優化。

同樣的，根據鎖類型和鎖對象構建mtr_memo_slot_t加入到m_impl.m_memo中。

插入數據

在插入數據過程中，包含大量的redo寫cache邏輯，例如更新二級索引頁的max trx id、寫undo log產生的redo(嵌套另外一個mtr)、修改數據頁產生的日誌。這裏我們只討論修改數據頁產生的日誌，進入函數page_cur_insert_rec_write_log:

Step 1: 調用函數mlog_open_and_write_index記錄索引相關信息

1. 調用mlog_open，分配足夠日誌寫入的內存地址，並返回內存指針
2. 初始化日誌記錄：mlog_write_initial_log_record_fast 寫入 |類型=MLOG\_COMP\_REC\_INSERT，1字節|space id | page no| space id 和page no采用一種壓縮寫入的方式（mach_write_compressed），根據數字的具體大小，選擇從1到4個字節記錄整數，節約redo空間，對應的解壓函數為mach_read_compressed
3. 寫入當前索引列個數，占兩個字節
4. 寫入行記錄上決定唯一性的列的個數，占兩個字節(dict_index_get_n_unique_in_tree) 對於聚集索引，就是PK上的列數；對於二級索引，就是二級索引列+PK列個數
5. 寫入每個列的長度信息，每個列占兩個字節 如果這是 varchar 列且最大長度超過255字節, len = 0x7fff；如果該列非空，len |= 0x8000；其他情況直接寫入列長度。

Step 2: 寫入記錄在page上的偏移量，占兩個字節

mach_write_to_2(log_ptr, page_offset(cursor_rec));

Step 3: 寫入記錄其它相關信息 （rec size, extra size, info bit，關於InnoDB的數據文件物理描述，我們以後再介紹，本文不展開）

Step 4: 將插入的記錄拷貝到redo文件，同時關閉mlog

memcpy(log_ptr, ins_ptr, rec_size);
mlog_close(mtr, log_ptr + rec_size);

通過上述流程，我們寫入了一個類型為MLOG_COMP_REC_INSERT的日誌記錄。由於特定類型的記錄都基於約定的格式，在崩潰恢復時也可以基於這樣的約定解析出日誌。

這裏只舉了一個非常簡單的例子，該mtr中只包含一條redo記錄。實際上mtr遍布整個InnoDB的邏輯，但只要遵循相同的寫入和讀取約定，並對寫入的單元（page）加上互斥鎖，就能從崩潰恢復。

更多的redo log記錄類型參見enum mlog_id_t。

在這個過程中產生的redo log都記錄在mtr.m_impl.m_log中，只有顯式提交mtr時，才會寫到公共buffer中。

提交mtr log

當提交一個mini transaction時，需要將對數據的更改記錄提交到公共buffer中，並將對應的臟頁加到flush list上。

入口函數為mtr_t::commit()，當修改產生臟頁或者日誌記錄時，調用mtr_t::Command::execute，執行過程如下：

Step 1: mtr_t::Command::prepare_write()

1. 若當前mtr的模式為MTR_LOG_NO_REDO 或者MTR_LOG_NONE，則獲取log_sys->mutex，從函數返回
2. 若當前要寫入的redo log記錄的大小超過log buffer的二分之一，則去擴大log buffer，大小約為原來的兩倍。
3. 持有log_sys->mutex
4. 調用函數log_margin_checkpoint_age檢查本次寫入： 如果本次產生的redo log size的兩倍超過redo log文件capacity，則打印一條錯誤信息；若本次寫入可能覆蓋檢查點，還需要去強制做一次同步chekpoint

5. 檢查本次修改的表空間是否是上次checkpoint後第一次修改，調用函數（fil_names_write_if_was_clean） 如果space->max_lsn = 0，表示自上次checkpoint後第一次修改該表空間： a. 修改space->max_lsn為當前log_sys->lsn； b. 調用fil_names_dirty_and_write將該tablespace加入到fil_system->named_spaces鏈表上； c. 調用fil_names_write寫入一條類型為MLOG_FILE_NAME的日誌，寫入類型、spaceid, page no(0)、文件路徑長度、以及文件路徑名。

   在mtr日誌末尾追加一個字節的MLOG_MULTI_REC_END類型的標記，表示這是多個日誌類型的mtr。

   Tips：在5.6及之前的版本中，每次crash recovery時都需要打開所有的ibd文件，如果表的數量非常多時，會非常影響崩潰恢復性能，因此從5.7版本開始，每次checkpoint後，第一次修改的文件名被記錄到redo log中，這樣在重啟從檢查點恢復時，就只打開那些需要打開的文件即可（WL#7142）

6. 如果不是從上一次checkpoint後第一次修改該表，則根據mtr中log的個數，或標識日誌頭最高位為MLOG_SINGLE_REC_FLAG，或附加一個1字節的MLOG_MULTI_REC_END日誌。

註意從prepare_write函數返回時是持有log_sys->mutex鎖的。

至此一條插入操作產生的mtr日誌格式有可能如下圖所示：

Step 2: mtr_t::Command::finish_write

將日誌從mtr中拷貝到公共log buffer。這裏有兩種方式

1. 如果mtr中的日誌較小，則調用函數log_reserve_and_write_fast，嘗試將日誌拷貝到log buffer最近的一個block。如果空間不足，走邏輯b)，否則直接拷貝

2. 檢查是否有足夠的空閑空間後，返回當前的lsn賦值給m_start_lsn（log_reserve_and_open(len)），隨後將日誌記錄寫入到log buffer中。

     m_start_lsn = log_reserve_and_open(len);
     mtr_write_log_t write_log;
     m_impl->m_log.for_each_block(write_log);
   

3. 在完成將redo 拷貝到log buffer後，需要調用log_close, 如果最後一個block未寫滿，則設置該block頭部的LOG_BLOCK_FIRST_REC_GROUP信息； 滿足如下情況時，設置log_sys->check_flush_or_checkpoint為true：

   • 當前寫入buffer的位置超過log buffer的一半
   • bp中最老lsn和當前lsn的距離超過log_sys->max_modified_age_sync
   • 當前未checkpoint的lsn age超過log_sys->max_checkpoint_age_async
   • 當前bp中最老lsn為0 （沒有臟頁）

   當check_flush_or_checkpoint被設置時，用戶線程在每次修改數據前調用log_free_check時，會根據該標記決定是否刷redo日誌或者臟頁。

註意log buffer遵循一定的格式，它以512字節對齊，和redo log文件的block size必須完全匹配。由於以固定block size組織結構，因此一個block中可能包含多個mtr提交的記錄，也可能一個mtr的日誌占用多個block。如下圖所示：

Step 3：如果本次修改產生了臟頁，獲取log_sys->log_flush_order_mutex，隨後釋放log_sys->mutex。

Step 4. 將當前Mtr修改的臟頁加入到flush list上，臟頁上記錄的lsn為當前mtr寫入的結束點lsn。基於上述加鎖邏輯，能夠保證flush list上的臟頁總是以LSN排序。

Step 5. 釋放log_sys->log_flush_order_mutex鎖

Step 6. 釋放當前mtr持有的鎖（主要是page latch）及分配的內存，mtr完成提交。

Redo 寫盤操作

有幾種場景可能會觸發redo log寫文件：

1. Redo log buffer空間不足時
2. 事務提交
3. 後臺線程
4. 做checkpoint
5. 實例shutdown時
6. binlog切換時

我們所熟悉的參數innodb_flush_log_at_trx_commit 作用於事務提交時，這也是最常見的場景：

• 當設置該值為1時，每次事務提交都要做一次fsync，這是最安全的配置，即使宕機也不會丟失事務；
• 當設置為2時，則在事務提交時只做write操作，只保證寫到系統的page cache，因此實例crash不會丟失事務，但宕機則可能丟失事務；
• 當設置為0時，事務提交不會觸發redo寫操作，而是留給後臺線程每秒一次的刷盤操作，因此實例crash將最多丟失1秒鐘內的事務。

下圖表示了不同配置值的持久化程度：

顯然對性能的影響是隨著持久化程度的增加而增加的。通常我們建議在日常場景將該值設置為1，但在系統高峰期臨時修改成2以應對大負載。

由於各個事務可以交叉的將事務日誌拷貝到log buffer中，因而一次事務提交觸發的寫redo到文件，可能隱式的幫別的線程“順便”也寫了redo log，從而達到group commit的效果。

寫redo log的入口函數為log_write_up_to，該函數的邏輯比較簡單，這裏不詳細描述，但有幾點說明下。

log_write_up_to邏輯重構

首先是在該代碼邏輯上，相比5.6及之前的版本，5.7在沒有更改日誌寫主要架構的基礎上重寫了log_write_up_to，讓其代碼更加可讀，同時消除一次多余的獲取log_sys->mutex，具體的(WL#7050)：

• 早期版本的innodb支持將redo寫到多個group中，但現在只支持一個group，因此移除相關的變量，消除log_write_up_to的第二個傳參；
• write redo操作一直持有log_sys->mutex, 所有隨後的write請求，不再進入condition wait, 而是通過log_sys->mutex序列化；
• 之前的邏輯中，在write一次redo後，需要釋放log_sys->mutex，再重新獲取，更新相關變量，新的邏輯消除了第二次獲取 log_sys->mutex；
• write請求的寫redo無需等待fsync，這意味著寫redo log文件和fsync文件可以同時進行。

理論上該改動可以幫助優化innodb_flush_log_at_trx_commit=2時的性能。

log write ahead

上面已經介紹過，InnoDB以512字節一個block的方式對齊寫入ib_logfile文件，但現代文件系統一般以4096字節為一個block單位。如果即將寫入的日誌文件塊不在OS Cache時，就需要將對應的4096字節的block讀入內存，修改其中的512字節，然後再把該block寫回磁盤。

為了解決這個問題，MySQL 5.7引入了一個新參數：innodb_log_write_ahead_size。當當前寫入文件的偏移量不能整除該值時，則補0，多寫一部分數據。這樣當寫入的數據是以磁盤block size對齊時，就可以直接write磁盤，而無需read-modify-write這三步了。

註意innodb_log_write_ahead_size的默認值為8196，你可能需要根據你的系統配置來修改該值，以獲得更好的效果。

Innodb redo log checksum

在寫入redo log到文件之前，redo log的每一個block都需要加上checksum校驗位，以防止apply了損壞的redo log。

然而在5.7.7版本之前版本，都是使用的InnoDB的默認checksum算法（稱為InnoDB checksum），這種算法的效率較低。因此在MySQL5.7.8以及Percona Server 5.6版本都支持使用CRC32的checksum算法，該算法可以引用硬件特性，因而具有非常高的效率。

在我的sysbench測試中，使用update_non_index，128個並發下TPS可以從55000上升到60000（非雙1），效果還是非常明顯的。

Redo checkpoint

InnoDB的redo log采用覆蓋循環寫的方式，而不是擁有無限的redo空間；即使擁有理論上極大的redo log空間，為了從崩潰中快速恢復，及時做checkpoint也是非常有必要的。

InnoDB的master線程大約每隔10秒會做一次redo checkpoint，但不會去preflush臟頁來推進checkpoint點。

通常普通的低壓力負載下，page cleaner線程的刷臟速度足以保證可作為檢查點的lsn被及時的推進。但如果系統負載很高時，redo log推進速度過快，而page cleaner來不及刷臟，這時候就會出現用戶線程陷入同步刷臟並做同checkpoint的境地，這種策略的目的是為了保證redo log能夠安全的寫入文件而不會覆蓋最近的檢查點。

redo checkpoint的入口函數為log_checkpoint，其執行流程如下：

Step1. 持有log_sys->mutex鎖，並獲取buffer pool的flush list鏈表尾的block上的lsn，這個lsn是buffer pool中未寫入數據文件的最老lsn，在該lsn之前的數據都保證已經寫入了磁盤。

Step 2. 調用函數fil_names_clear

1. 如果log_sys->append_on_checkpoint被設置，表示當前有會話正處於DDL的commit階段，但還沒有完成，向redo log buffer中追加一個新的redo log記錄 該邏輯由commita5ecc38f44abb66aa2024c70e37d1f4aa4c8ace9引入，用於解決DDL過程中crash的問題

2. 掃描fil_system->named_spaces上的fil_space_t對象，如果表空間fil_space_t->max_lsn小於當前準備做checkpoint的Lsn，則從鏈表上移除並將max_lsn重置為0。同時為每個被修改的表空間構建MLOG_FILE_NAME類型的redo記錄。（這一步未來可能會移除，只要跟蹤第一次修改該表空間的min_lsn，並且min_lsn大於當前checkpoint的lsn，就可以忽略調用fil_names_write）

3. 寫入一個MLOG_CHECKPOINT類型的CHECKPOINT REDO記錄，並記入當前的checkpoint LSN

Step3 . fsync redo log到當前的lsn

Step4. 寫入checkpoint信息

函數：log_write_checkpoint_info --> log_group_checkpoint

checkpoint信息被寫入到了第一個iblogfile的頭部，但寫入的文件偏移位置比較有意思，當log_sys->next_checkpoint_no為奇數時，寫入到LOG_CHECKPOINT_2（3 *512字節）位置，為偶數時，寫入到LOG_CHECKPOINT_1（512字節）位置。

大致結構如下圖所示：

在crash recover重啟時，會讀取記錄在checkpoint中的lsn信息，然後從該lsn開始掃描redo日誌。

Checkpoint操作由異步IO線程執行寫入操作，當完成寫入後，會調用函數log_io_complete執行如下操作：

1. fsync 被修改的redo log文件

2. 更新相關變量：

    log_sys->next_checkpoint_no++
    log_sys->last_checkpoint_lsn = log_sys->next_checkpoint_lsn
   

3. 釋放log_sys->checkpoint_lock鎖

然而在5.7之前的版本中，我們並沒有根據即將寫入的數據大小來預測當前是否需要做checkpoint，而是在寫之前檢測，保證redo log文件中有”足夠安全”的空間（而非絕對安全）。假定我們的ib_logfile文件很小，如果我們更新一個非常大的blob字段，就有可能覆蓋掉未checkpoint的redo log， 大神Jeremy cole 在buglist上提了一個Bug#69477。

為了解決該問題，在MySQL 5.6.22版本開始，對blob列做了限制: 當redo log的大小超過 (innodb_log_file_size *innodb_log_files_in_group)的十分之一時，就會給應用報錯，然而這可能會帶來不兼容問題，用戶會發現，早期版本用的好好的SQL，在最新版本的5.6裏居然跑不動了。

在5.7.5及之後版本，則沒有5.6的限制，其核心思路是每操作4個外部存儲頁，就檢查一次redo log是否足夠用，如果不夠，就會推進checkpoint的lsn。當然具體的實現比較復雜，感興趣的參考如下comit：f88a5151b18d24303746138a199db910fbb3d071

文件日誌

除了普通的redo log日誌外，InnoDB還增加了一種文件日誌類型，即通過創建特定文件，賦予特定的文件名來標示某種操作。目前有兩種類型：undo table space truncate操作及用戶表空間truncate操作。通過文件日誌可以保證這些操作的原子性。

Undo tablespace truncate

我們知道undo log是MVCC多版本控制的核心模塊，一直以來undo log都存儲在ibdata系統表空間中，而從5.6開始，用戶可以把undo log存儲到獨立的tablespace中，並拆分成多個Undo log文件，但無法縮小文件的大小。而長時間未提交事務導致大量undo空間的浪費的例子，在我們的生產場景也不是一次兩次了。

5.7版本的undo log的truncate操作是基於獨立undo 表空間來實現的。在purge線程選定需要清理的undo tablespace後，開始做truncate操作之前，會先創建一個命名為undo_space_id_trunc.log的文件，然後將undo tablespace truncate 到10M大小，在完成truncate後刪除日誌文件。

如果在truncate過程中實例崩潰重啟，若發現該文件存在，則認為truncate操作沒有完成，需要重做一遍。註意這種文件操作是無法回滾的。

User tablespace truncate

類似的，在5.7版本裏，也是通過日誌文件來保證用戶表空間truncate操作的原子性。在做實際的文件操作前，創建一個命名為ib_space-id_table-id_trunc.log的文件。在完成操作後刪除。

同樣的，在崩潰重啟時，如果檢查到該文件存在，需要確認是否重做。

InnoDB shutdown

實例關閉分為兩種，一種是正常shutdown（非fast shutdown），實例重啟時無需apply日誌，另外一種是異常shutdown，包括實例crash以及fast shutdown。

當正常shutdown實例時，會將所有的臟頁都刷到磁盤，並做一次完全同步的checkpoint；同時將最後的lsn寫到系統表ibdata的第一個page中（函數fil_write_flushed_lsn）。在重啟時，可以根據該lsn來判斷這是不是一次正常的shutdown，如果不是就需要去做崩潰恢復邏輯。

參閱函數logs_empty_and_mark_files_at_shutdown。

關於異常重啟的邏輯，由於崩潰恢復涉及到的模塊眾多，邏輯復雜，我們將在下期月報單獨進行描述。

MySQL · 引擎特性 · InnoDB redo log漫遊（轉）