面試官：在數(shù)據(jù)庫恢復(fù)過程，InnoDB如何定位到具體的數(shù)據(jù)文件呢？

InnoDB作為事務(wù)性引擎，使用write-ahead logging(WAL)機制保證ACID中的Automicity和Durability，使用undo機制保證ACID中的Consistency和Isolation。

按照WAL和undo的機制，形成以下兩個原則：

1、數(shù)據(jù)塊的更改需要先記錄redo日志。

2、數(shù)據(jù)塊的更改需要先寫入undo。

根據(jù)這兩個原則，InnoDB更新數(shù)據(jù)的基本流程可以簡單的總結(jié)為：記錄需要更改undo record的redo log記錄需要更改data record的redo log寫入redo log寫入undo record更新data record

如果MySQL實例異常crash，那么重啟過程中首先會進行InnoDB recovery。 即：根據(jù)last checkpoint點，順序讀取后面的redo log，按照先前滾，再回滾的原則， 應(yīng)用所有的redo log。

因為redo record中記錄著數(shù)據(jù)塊的地址(space_id+page_no)，所以recovery的過程首先會執(zhí)行合并相同數(shù)據(jù)塊的操作，以加快recovery的過程。

那么mysql數(shù)據(jù)庫怎么根據(jù)space_id找到對應(yīng)IDB數(shù)據(jù)文件？ 因為在恢復(fù)的過程中，InnoDB只load了redo文件和系統(tǒng)表空間文件，如何查找InnoDB的數(shù)據(jù)文件呢？InnoDB的數(shù)據(jù)字典dict_table_t結(jié)構(gòu)中也保存了對應(yīng)關(guān)系，但數(shù)據(jù)字典受redo保護，recovery的過程中不可用。掃描datadir的所有數(shù)據(jù)文件，讀取page中保存的space_id，建立space_id和數(shù)據(jù)文件的對應(yīng)關(guān)系。 MySQL目前采用第二種方式，但帶來了一個問題，當(dāng)設(shè)置了innodb_file_per_table后，每一個表對應(yīng)一個表空間，那么需要讀取所有的目錄下的所有Innodb數(shù)據(jù)文件，這樣就會嚴重的影響了recovery的時間。

MySQL 5.7改進策略：

MySQL 5.7中，在redo log中增加了一種新的record類型，即MLOG_FILE_NAME，記錄了自last checkpoint以來更改的數(shù)據(jù)文件的file name。 這樣在應(yīng)用的時候，直接根據(jù)文件名就可以找到數(shù)據(jù)文件。

Oracle數(shù)據(jù)庫recovery的過程中，有沒有這個問題呢？ 答案是沒有。

看下Oracle的設(shè)計機制:

oracle同樣在系統(tǒng)表空間中記錄了數(shù)據(jù)字典，受redo保護，可以通過DBA_開頭的表來查詢。但Oracle還維護了一個control file，控制文件中記錄了database name，redo file，datafile，backup等信息，通過v$開頭的表查詢。 當(dāng)Oracle在recovery的過程中，需要數(shù)據(jù)庫在mount狀態(tài)下，即打開了控制文件，這時數(shù)據(jù)字典還不可用(DB沒有open)，在應(yīng)用redo log的時候，根據(jù)控制文件中的v$datafile，檢索file_id和file_name的對應(yīng)關(guān)系。 MySQL是根據(jù)datadir，innodb_data_home_dir，innodb_log_group_home_dir等幾個目錄配置，通過文件系統(tǒng)的查找，找到相應(yīng)文件的，而Oracle維護了一個集中式的control file管理這些初始加載的文件地址。

后面會分享更多devops和DBA方面的內(nèi)容，感興趣的朋友可以關(guān)注下~