mysql innodb redolog_MySQL · 引擎特性 · InnoDB redo log漫游（转）
前言
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 文件相關的成員變量包括：
變量名描述
log_groups
日志組，當前版本僅支持一組日志，對應類型為?log_group_t?，包含了當前日志組的文件個數、每個文件的大小、space id等信息
lsn_t log_group_capacity
表示當前日志文件的總容量，值為:(Redo log文件總大小 - redo 文件個數 * LOG_FILE_HDR_SIZE) * 0.9，LOG_FILE_HDR_SIZE 為 4*512 字節
lsn_t max_modified_age_async
異步 preflush dirty page 點
lsn_t max_modified_age_sync
同步 preflush dirty page 點
lsn_t max_checkpoint_age_async
異步 checkpoint 點
lsn_t max_checkpoint_age
同步 checkpoint 點
上述幾個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結構體主要成員如下表所示：
變量名描述
ulint n_files
Ib_logfile的文件個數
lsn_t file_size
文件大小
ulint space_id
Redo log 的space id, 固定大小，值為SRV_LOG_SPACE_FIRST_ID
ulint state
LOG_GROUP_OK 或者 LOG_GROUP_CORRUPTED
lsn_t lsn
該group內寫到的lsn
lsn_t lsn_offset
上述lsn對應的文件偏移量
byte** file_header_bufs
Buffer區域，用于設定日志文件頭信息，并寫入ib logfile。當切換到新的ib_logfile時，更新該文件的起始lsn，寫入頭部。 頭部信息還包含： LOG_GROUP_ID, LOG_FILE_START_LSN(當前文件起始lsn)、LOG_FILE_WAS_CREATED_BY_HOT_BACKUP(函數log_group_file_header_flush)
lsn_t scanned_lsn
用于崩潰恢復時輔助記錄掃描到的lsn號
byte* checkpoint_buf
Checkpoint緩沖區，用于向日志文件寫入checkpoint信息(下文詳細描述)
與redo log 內存緩沖區相關的成員變量包括：
變量名描述
ulint buf_free
Log buffer中當前空閑可寫的位置
byte* buf
Log buffer起始位置指針
ulint buf_size
Log buffer 大小，受參數innodb_log_buffer_size控制，但可能會自動extend
ulint max_buf_free
值為log_sys->buf_size / LOG_BUF_FLUSH_RATIO - LOG_BUF_FLUSH_MARGIN, 其中： LOG_BUF_FLUSH_RATIO=2, LOG_BUF_FLUSH_MARGIN=(4 * 512 + 4* page_size) ,page_size默認為16k,當buf_free超過該值時，可能觸發用戶線程去寫redo；在事務拷redo 到buffer后，也會判斷該值，如果超過buf_free，設置log_sys->check_flush_or_checkpoint為true
ulint buf_next_to_write
Log buffer偏移量，下次寫入redo文件的起始位置，即本次寫入的結束位置
volatile bool is_extending
Log buffer是否正在進行擴展 (防止過大的redo log entry無法寫入buffer), 實際上，當寫入的redo log長度超過buf_size/2時，就會去調用函數log_buffer_extend,一旦擴展Buffer，就不會在縮減回去了！
ulint write_end_offset
本次寫入的結束位置偏移量(從邏輯來看有點多余，直接用log_sys->buf_free就行了)
和Checkpoint檢查點相關的成員變量：
變量名描述
ib_uint64_t next_checkpoint_no
每完成一次checkpoint遞增該值
lsn_t last_checkpoint_lsn
最近一次checkpoint時的lsn，每完成一次checkpoint，將next_checkpoint_lsn的值賦給last_checkpoint_lsn
lsn_t next_checkpoint_lsn
下次checkpoint的lsn(本次發起的checkpoint的lsn)
mtr_buf_t* append_on_checkpoint
5.7新增，在做DDL時(例如增刪列)，會先將包含MLOG_FILE_RENAME2日志記錄的buf掛到這個變量上。 在DDL完成后，再清理掉。(log_append_on_checkpoint),主要是防止DDL期間crash產生的數據詞典不一致。 該變量在如下commit加上： a5ecc38f44abb66aa2024c70e37d1f4aa4c8ace9
ulint n_pending_checkpoint_writes
大于0時，表示有一個checkpoint寫入操作正在進行。用戶發起checkpoint時，遞增該值。后臺線程完成checkpoint寫入后，遞減該值(log_io_complete)
rw_lock_t checkpoint_lock
checkpoint鎖，每次寫checkpoint信息時需要加x鎖。由異步io線程釋放該x鎖
byte* checkpoint_buf
Checkpoint信息緩沖區，每次checkpoint前，先寫該buf，再將buf刷到磁盤
其他狀態變量
變量名描述
bool check_flush_or_checkpoint
當該變量被設置時，用戶線程可能需要去檢查釋放要刷log buffer、或是做preflush、checkpoint等以防止Redo 空間不足
lsn_t write_lsn
最近一次完成寫入到文件的LSN
lsn_t current_flush_lsn
當前正在fsync到的LSN
lsn_t flushed_to_disk_lsn
最近一次完成fsync到文件的LSN
ulint n_pending_flushes
表示pending的redo fsync，這個值最大為1
os_event_t flush_event
若當前有正在進行的fsync，并且本次請求也是fsync操作，則需要等待上次fsync操作完成
log_sys與日志文件和日志緩沖區的關系可用下圖來表示：
Mini transaction
Mini transaction(簡稱mtr)是InnoDB對物理數據文件操作的最小事務單元，用于管理對Page加鎖、修改、釋放、以及日志提交到公共buffer等工作。一個mtr操作必須是原子的，一個事務可以包含多個mtr。每個mtr完成后需要將本地產生的日志拷貝到公共緩沖區，將修改的臟頁放到flush list上。
mtr事務對應的類為mtr_t,?mtr_t::Impl中保存了當前mtr的相關信息，包括:
變量名描述
mtr_buf_t m_memo
用于存儲該mtr持有的鎖類型
mtr_buf_t m_log
存儲redo log記錄
bool m_made_dirty
是否產生了至少一個臟頁
bool m_inside_ibuf
是否在操作change buffer
bool m_modifications
是否修改了buffer pool page
ib_uint32_t m_n_log_recs
該mtr log記錄個數
mtr_log_t m_log_mode
Mtr的工作模式，包括四種： MTR_LOG_ALL：默認模式，記錄所有會修改磁盤數據的操作；MTR_LOG_NONE：不記錄redo，臟頁也不放到flush list上；MTR_LOG_NO_REDO：不記錄redo，但臟頁放到flush list上；MTR_LOG_SHORT_INSERTS：插入記錄操作REDO，在將記錄從一個page拷貝到另外一個新建的page時用到，此時忽略寫索引信息到redo log中。(參閱函數page_cur_insert_rec_write_log)
fil_space_t* m_user_space
當前mtr修改的用戶表空間
fil_space_t* m_undo_space
當前mtr修改的undo表空間
fil_space_t* m_sys_space
當前mtr修改的系統表空間
mtr_state_t m_state
包含四種狀態: MTR_STATE_INIT、MTR_STATE_COMMITTING、 MTR_STATE_COMMITTED
在修改或讀一個數據文件中的數據時，一般是通過mtr來控制對對應page或者索引樹的加鎖，在5.7中，有以下幾種鎖類型(mtr_memo_type_t)：
變量名描述
MTR_MEMO_PAGE_S_FIX
用于PAGE上的S鎖
MTR_MEMO_PAGE_X_FIX
用于PAGE上的X鎖
MTR_MEMO_PAGE_SX_FIX
用于PAGE上的SX鎖，以上鎖通過mtr_memo_push 保存到mtr中
MTR_MEMO_BUF_FIX
PAGE上未加讀寫鎖，僅做buf fix
MTR_MEMO_S_LOCK
S鎖，通常用于索引鎖
MTR_MEMO_X_LOCK
X鎖，通常用于索引鎖
MTR_MEMO_SX_LOCK
SX鎖，通常用于索引鎖，以上3個鎖，通過mtr_s/x/sx_lock加鎖，通過mtr_memo_release釋放鎖
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主要包括：
初始化mtr的各個狀態變量
默認模式為MTR_LOG_ALL，表示記錄所有的數據變更
mtr狀態設置為ACTIVE狀態(MTR_STATE_ACTIVE)
為鎖管理對象和日志管理對象初始化內存(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記錄索引相關信息
調用mlog_open，分配足夠日志寫入的內存地址，并返回內存指針
初始化日志記錄：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
寫入當前索引列個數，占兩個字節
寫入行記錄上決定唯一性的列的個數，占兩個字節(dict_index_get_n_unique_in_tree) 對于聚集索引，就是PK上的列數；對于二級索引，就是二級索引列+PK列個數
寫入每個列的長度信息，每個列占兩個字節 如果這是 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()
若當前mtr的模式為MTR_LOG_NO_REDO 或者MTR_LOG_NONE，則獲取log_sys->mutex，從函數返回
若當前要寫入的redo log記錄的大小超過log buffer的二分之一，則去擴大log buffer，大小約為原來的兩倍。
持有log_sys->mutex
調用函數log_margin_checkpoint_age檢查本次寫入： 如果本次產生的redo log size的兩倍超過redo log文件capacity，則打印一條錯誤信息；若本次寫入可能覆蓋檢查點，還需要去強制做一次同步chekpoint
檢查本次修改的表空間是否是上次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)
如果不是從上一次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。這里有兩種方式
如果mtr中的日志較小，則調用函數log_reserve_and_write_fast，嘗試將日志拷貝到log buffer最近的一個block。如果空間不足，走邏輯b)，否則直接拷貝
檢查是否有足夠的空閑空間后，返回當前的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);
在完成將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寫文件：
Redo log buffer空間不足時
事務提交
后臺線程
做checkpoint
實例shutdown時
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
如果log_sys->append_on_checkpoint被設置，表示當前有會話正處于DDL的commit階段，但還沒有完成，向redo log buffer中追加一個新的redo log記錄 該邏輯由commita5ecc38f44abb66aa2024c70e37d1f4aa4c8ace9引入，用于解決DDL過程中crash的問題
掃描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)
寫入一個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執行如下操作：
fsync 被修改的redo log文件
更新相關變量：
log_sys->next_checkpoint_no++
log_sys->last_checkpoint_lsn = log_sys->next_checkpoint_lsn
釋放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 redolog_MySQL · 引擎特性 · InnoDB redo log漫游（转）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Android-jsoup爬虫
- 下一篇： 011——数组（十一）array_mer