MySQL5.7:新的日誌型別MLOG_FILE_NAME來避免崩潰恢復時掃描全部ibd
前言
對應 Worklog:http://dev.mysql.com/worklog/task/?id=7142
對應change log entry:
Incompatible Change: A new log record type (MLOG_FILE_NAME) is used to identify file-per-table tablespaces that have been modified since the last checkpoint. This enhancement simplifies tablespace discovery during crash recovery and eliminates scans on the file system prior to redo log application. For more information about the benefits of this enhancement, see Tablespace Discovery During Crash Recovery.
This enhancement changes the redo log format, requiring that MySQL be shut down cleanly before upgrading to or downgrading from MySQL 5.7.5.
問題:
改進的主要目的是為了消除在crash recovery時對檔案目錄的掃描,因為在innodb層無法根據redo log中的space id直接找到對應的檔案,因此需要開啟每個ibd的第一個page來進行判定。
新的修改簡化了上述邏輯,只有在一次checkpoint後被修改了的表才需要被讀取,其他的乾淨的表空間無需掃描。 在WL#7142中也處理了類似RENAME這樣的崩潰恢復邏輯,不在本文的討論範圍之內,後續單獨開文討論。
更改:
1.REDO LOG型別修改
MLOG_FILE_CREATE2、MLOG_FILE_CREATE:使用MLOG_FILE_NAME來代替
MLOG_FILE_RENAME:使用MLOG_FILE_RENAME2來代替
增加新型別:
MLOG_FILE_RENAME2:(space_id, first_page_number, filename, new_filename)
MLOG_FILE_CREATE:(space_id, name)
MLOG_CHECKPOINT
詳細見:enum mlog_id_t 列舉型別中關於各個型別的註釋
2.Mini Transaction事務提交時的修改
當需要修改資料頁時,在開啟一個mini transaction後,需要:
mtr_start(&mtr);
mtr.set_named_space(index->space);
set_named_space 會將當前的space id儲存到mtr_t::m_named_space中
mtr_commit時,如果對資料做了修改,那麼在5.7中分為兩步。
入口函式:mtr_t::Command::execute
a.mtr_t::Command::prepare_write()
#根據set_named_space 函式設定的space id,進行判斷:
fil_space_t* space
= is_predefined_tablespace(m_impl->m_named_space)
? NULL
: fil_names_write(m_impl->m_named_space, m_impl->m_mtr);
如果是預定義的系統表空間(ibdata, undo space ,tmp space),space = NULL; 否則呼叫函式 fil_names_write(m_impl->m_named_space, m_impl->m_mtr)寫入一個MLOG_FILE_NAME型別的REDO記錄;
#如果該space是上次CHECKPOINT後第一次被修改(呼叫 fil_names_dirty(space)),需要append一個1位元組的MLOG_MULTI_REC_END型別,因為當前mtr肯定大於1個log 記錄了(一個mtr可能包含多個log rec)
在函式fil_names_dirty中,會判斷space->max_lsn值是否為0,如果為0,表示第一次修改,加入到fil_system->named_spaces連結串列中;否則,設定space->max_lsn為當前的log_sys->lsn; (後面再說何時reset max_lsn為0)
#否則,需要忽略掉在fil_names_write寫入的REDO記錄。
b.mtr_t::Command::finish_write
將redo log從cache寫入redo log 公共buffer
3. Redo checkpoint
對應函式log_checkpoint
這裡會呼叫函式fil_names_clear,遍歷fil_system->named_spaces連結串列,如果space->max_lsn的值小於當前做checkpoint的LSN(在該LSN之前的髒頁已經刷盤),則將其中每個space->max_lsn設定為0,並從連結串列取出。同時寫一個MLOG_FILE_NAME日誌(所有named_spaces上的成員)。
然後寫一個MLOG_CHECKPOINT日誌,參考函式:mtr_t::commit_checkpoint。
因此這個mini transaction應該包含fil_system->named_spaces連結串列上每個成員的MLOG_FILE_NAME日誌以及緊隨其後的一個MLOG_CHECKPOINT日誌
4.崩潰恢復
在crash recovery時,會有一個記憶體結構物件來維護space id和表名的對映關係:
typedef std::map<
ulint,
file_name_t,
std::less<ulint>,
ut_allocator<std::pair<const ulint, file_name_t> > > recv_spaces_t;
static recv_spaces_t recv_spaces;
參考函式:
recv_parse_or_apply_log_rec_body–>fil_name_parse –>fil_name_process
相關程式碼:
http://bazaar.launchpad.net/~mysql/mysql-server/5.7/revision/7825
http://bazaar.launchpad.net/~mysql/mysql-server/5.7/revision/7829
http://bazaar.launchpad.net/~mysql/mysql-server/5.7/revision/7888
http://bazaar.launchpad.net/~mysql/mysql-server/5.7/revision/7966
http://bazaar.launchpad.net/~mysql/mysql-server/5.7/revision/8152
http://bazaar.launchpad.net/~mysql/mysql-server/5.7/revision/8560
相關文章
- IOS 崩潰日誌分析iOS
- Mysql5.7利用frm與ibd恢復資料MySql
- InnoDB 崩潰恢復機制
- WWDC 2018:理解崩潰以及崩潰日誌
- MySQL 崩潰恢復過程分析MySql
- MySQL 引擎特性:InnoDB崩潰恢復MySql
- android Activity崩潰日誌收集Android
- 【安卓筆記】崩潰日誌收集安卓筆記
- win10查詢崩潰日誌方法 win10怎麼檢視崩潰日誌Win10
- Linux崩潰恢復工具--CRK(轉)Linux
- 崩潰日誌的欄位簡單說明
- crash日誌符號化,以分析崩潰符號
- 簡便地Android崩潰日誌收集Android
- 儲存崩潰資料恢復過程;資料恢復案例資料恢復
- iOS 避免常見崩潰(一)iOS
- iOS 避免常見崩潰(二)iOS
- 資料庫崩潰恢復表結構的方法資料庫
- 重做日誌的恢復
- 恢復案例:無歸檔,丟失全部控制檔案、日誌檔案恢復案例
- 當前日誌組全部損壞的恢復
- 【儲存資料恢復】EMC某型號儲存raid5崩潰的資料恢復案例資料恢復AI
- Android 崩潰日誌採集元件-DhccCrashLibAndroid元件
- 恢復重做日誌
- 當前聯機日誌和其他聯機日誌恢復的區別
- RMAN恢復案例:無恢復目錄,丟失全部資料檔案、控制檔案、日誌檔案恢復
- 伺服器崩潰硬碟壞道資料恢復伺服器硬碟資料恢復
- Flutter異常捕獲和Crash崩潰日誌收集Flutter
- 基於Redo Log和Undo Log的MySQL崩潰恢復流程MySql
- AIX系統崩潰後oracle資料庫的恢復方法AIOracle資料庫
- 【恢復】Redo日誌檔案丟失的恢復
- oracle 恢復重做日誌Oracle
- 【故障恢復】【驚魂】ORACLE聯機日誌檔案無故全部消失Oracle
- WkWebView 令人崩潰的崩潰WebView
- Web應用型別掃描識別工具WhatWebWeb型別
- oracle 線上日誌全部丟失的資料恢復Oracle資料恢復
- 惠普塔式伺服器崩潰資料恢復成功案例伺服器資料恢復
- 【MySQL】崩潰恢復問題解決:Forcing InnoDB RecoveryMySql
- 使用索引快速全掃描(Index FFS)避免全表掃描的若干場景索引Index