概述

數(shù)據(jù)庫(kù)系統(tǒng)與文件系統(tǒng)很大的區(qū)別在于數(shù)據(jù)庫(kù)能保證操作的原子性，一個(gè)操作要么不做要么都做，即使在數(shù)據(jù)庫(kù)宕機(jī)的情況下，也不會(huì)出現(xiàn)操作一半的情況，這個(gè)就需要數(shù)據(jù)庫(kù)的日志和一套完善的崩潰恢復(fù)機(jī)制來(lái)保證。下面簡(jiǎn)單介紹一下InnoDB的崩潰恢復(fù)流程。 

[[276536]]

相關(guān)概念

lsn: 可以理解為數(shù)據(jù)庫(kù)從創(chuàng)建以來(lái)產(chǎn)生的redo日志量，這個(gè)值越大，說(shuō)明數(shù)據(jù)庫(kù)的更新越多，也可以理解為更新的時(shí)刻。此外，每個(gè)數(shù)據(jù)頁(yè)上也有一個(gè)lsn，表示最后被修改時(shí)的lsn，值越大表示越晚被修改。比如，數(shù)據(jù)頁(yè)A的lsn為100，數(shù)據(jù)頁(yè)B的lsn為200，checkpoint lsn為150，系統(tǒng)lsn為300，表示當(dāng)前系統(tǒng)已經(jīng)更新到300，小于150的數(shù)據(jù)頁(yè)已經(jīng)被刷到磁盤(pán)上，因此數(shù)據(jù)頁(yè)A的最新數(shù)據(jù)一定在磁盤(pán)上，而數(shù)據(jù)頁(yè)B則不一定，有可能還在內(nèi)存中。

redo日志: 現(xiàn)代數(shù)據(jù)庫(kù)都需要寫(xiě)redo日志，例如修改一條數(shù)據(jù)，首先寫(xiě)redo日志，然后再寫(xiě)數(shù)據(jù)。在寫(xiě)完redo日志后，就直接給客戶端返回成功。這樣雖然看過(guò)去多寫(xiě)了一次盤(pán)，但是由于把對(duì)磁盤(pán)的隨機(jī)寫(xiě)入(寫(xiě)數(shù)據(jù))轉(zhuǎn)換成了順序的寫(xiě)入(寫(xiě)redo日志)，性能有很大幅度的提高。當(dāng)數(shù)據(jù)庫(kù)掛了之后，通過(guò)掃描redo日志，就能找出那些沒(méi)有刷盤(pán)的數(shù)據(jù)頁(yè)(在崩潰之前可能數(shù)據(jù)頁(yè)僅僅在內(nèi)存中修改了，但是還沒(méi)來(lái)得及寫(xiě)盤(pán))，保證數(shù)據(jù)不丟。

undo日志: 數(shù)據(jù)庫(kù)還提供類似撤銷的功能，當(dāng)你發(fā)現(xiàn)修改錯(cuò)一些數(shù)據(jù)時(shí)，可以使用rollback指令回滾之前的操作。這個(gè)功能需要undo日志來(lái)支持。此外，現(xiàn)代的關(guān)系型數(shù)據(jù)庫(kù)為了提高并發(fā)(同一條記錄，不同線程的讀取不沖突，讀寫(xiě)和寫(xiě)讀不沖突，只有同時(shí)寫(xiě)才沖突)，都實(shí)現(xiàn)了類似MVCC的機(jī)制，在InnoDB中，這個(gè)也依賴undo日志。為了實(shí)現(xiàn)統(tǒng)一的管理，與redo日志不同，undo日志在Buffer Pool中有對(duì)應(yīng)的數(shù)據(jù)頁(yè)，與普通的數(shù)據(jù)頁(yè)一起管理，依據(jù)LRU規(guī)則也會(huì)被淘汰出內(nèi)存，后續(xù)再?gòu)拇疟P(pán)讀取。與普通的數(shù)據(jù)頁(yè)一樣，對(duì)undo頁(yè)的修改，也需要先寫(xiě)redo日志。

檢查點(diǎn): 英文名為checkpoint。數(shù)據(jù)庫(kù)為了提高性能，數(shù)據(jù)頁(yè)在內(nèi)存修改后并不是每次都會(huì)刷到磁盤(pán)上。checkpoint之前的數(shù)據(jù)頁(yè)保證一定落盤(pán)了，這樣之前的日志就沒(méi)有用了(由于InnoDB redolog日志循環(huán)使用，這時(shí)這部分日志就可以被覆蓋)，checkpoint之后的數(shù)據(jù)頁(yè)有可能落盤(pán)，也有可能沒(méi)有落盤(pán)，所以checkpoint之后的日志在崩潰恢復(fù)的時(shí)候還是需要被使用的。InnoDB會(huì)依據(jù)臟頁(yè)的刷新情況，定期推進(jìn)checkpoint，從而減少數(shù)據(jù)庫(kù)崩潰恢復(fù)的時(shí)間。檢查點(diǎn)的信息在第一個(gè)日志文件的頭部。

崩潰恢復(fù): 用戶修改了數(shù)據(jù)，并且收到了成功的消息，然而對(duì)數(shù)據(jù)庫(kù)來(lái)說(shuō)，可能這個(gè)時(shí)候修改后的數(shù)據(jù)還沒(méi)有落盤(pán)，如果這時(shí)候數(shù)據(jù)庫(kù)掛了，重啟后，數(shù)據(jù)庫(kù)需要從日志中把這些修改后的數(shù)據(jù)給撈出來(lái)，重新寫(xiě)入磁盤(pán)，保證用戶的數(shù)據(jù)不丟。這個(gè)從日志中撈數(shù)據(jù)的過(guò)程就是崩潰恢復(fù)的主要任務(wù)，也可以成為數(shù)據(jù)庫(kù)前滾。當(dāng)然，在崩潰恢復(fù)中還需要回滾沒(méi)有提交的事務(wù)，提交沒(méi)有提交成功的事務(wù)。由于回滾操作需要undo日志的支持，undo日志的完整性和可靠性需要redo日志來(lái)保證，所以崩潰恢復(fù)先做redo前滾，然后做undo回滾。

數(shù)據(jù)庫(kù)崩潰恢復(fù)過(guò)程

下面看一下數(shù)據(jù)庫(kù)崩潰恢復(fù)過(guò)程。整個(gè)過(guò)程都在引擎初始化階段完成(innobase_init)，其中最主要的函數(shù)是innobase_start_or_create_for_mysql，innodb通過(guò)這個(gè)函數(shù)完成創(chuàng)建和初始化，包括崩潰恢復(fù)。首先來(lái)介紹一下數(shù)據(jù)庫(kù)的前滾。

崩潰恢復(fù)相關(guān)參數(shù)解析

1、innodb_fast_shutdown:

innodb_fast_shutdown = 0。這個(gè)表示在MySQL關(guān)閉的時(shí)候，執(zhí)行slow shutdown，不但包括日志的刷盤(pán)，數(shù)據(jù)頁(yè)的刷盤(pán)，還包括數(shù)據(jù)的清理(purge)，ibuf的合并，buffer pool dump以及l(fā)azy table drop操作(如果表上有未完成的操作，即使執(zhí)行了drop table且返回成功了，表也不一定立刻被刪除)。 innodb_fast_shutdown = 1。這個(gè)是默認(rèn)值，表示在MySQL關(guān)閉的時(shí)候，僅僅把日志和數(shù)據(jù)刷盤(pán)。 innodb_fast_shutdown = 2。這個(gè)表示關(guān)閉的時(shí)候，僅僅日志刷盤(pán)，其他什么都不做，就好像MySQL crash了一樣。 這個(gè)參數(shù)值越大，MySQL關(guān)閉的速度越快，但是啟動(dòng)速度越慢，相當(dāng)于把關(guān)閉時(shí)候需要做的工作挪到了崩潰恢復(fù)上。另外，如果MySQL要升級(jí)，建議使用第一種方式進(jìn)行一次干凈的shutdown。

2、innodb_force_recovery

這個(gè)參數(shù)主要用來(lái)控制InnoDB啟動(dòng)時(shí)候做哪些工作，數(shù)值越大，做的工作越少，啟動(dòng)也更加容易，但是數(shù)據(jù)不一致的風(fēng)險(xiǎn)也越大。當(dāng)MySQL因?yàn)槟承┎豢煽氐脑虿荒軉?dòng)時(shí)，可以設(shè)置這個(gè)參數(shù)，從1開(kāi)始逐步遞增，知道MySQL啟動(dòng)，然后使用SELECT INTO OUTFILE把數(shù)據(jù)導(dǎo)出，盡最大的努力減少數(shù)據(jù)丟失。 innodb_force_recovery = 0。這個(gè)是默認(rèn)的參數(shù)，啟動(dòng)的時(shí)候會(huì)做所有的事情，包括redo日志應(yīng)用，undo日志回滾，啟動(dòng)后臺(tái)master和purge線程，ibuf合并。檢測(cè)到了數(shù)據(jù)頁(yè)損壞了，如果是系統(tǒng)表空間的，則會(huì)crash，用戶表空間的，則打錯(cuò)誤日志。

innodb_force_recovery = 1。如果檢測(cè)到數(shù)據(jù)頁(yè)損壞了，不會(huì)crash也不會(huì)報(bào)錯(cuò)(buf_page_io_complete)，啟動(dòng)的時(shí)候也不會(huì)校驗(yàn)表空間第一個(gè)數(shù)據(jù)頁(yè)的正確性(fil_check_first_page)，表空間無(wú)法訪問(wèn)也繼續(xù)做崩潰恢復(fù)(fil_open_single_table_tablespace、fil_load_single_table_tablespace)，ddl操作不能進(jìn)行(check_if_supported_inplace_alter)，同時(shí)數(shù)據(jù)庫(kù)也被不能進(jìn)行寫(xiě)入操作(row_insert_for_mysql、row_update_for_mysql等)，所有的prepare事務(wù)也會(huì)被回滾(trx_resurrect_insert、trx_resurrect_update_in_prepared_state)。這個(gè)選項(xiàng)還是很常用的，數(shù)據(jù)頁(yè)可能是因?yàn)榇疟P(pán)壞了而損壞了，設(shè)置為1，能保證數(shù)據(jù)庫(kù)正常啟動(dòng)。 innodb_force_recovery = 2。除了設(shè)置1之后的操作不會(huì)運(yùn)行，后臺(tái)的master和purge線程就不會(huì)啟動(dòng)了(srv_master_thread、srv_purge_coordinator_thread等)，當(dāng)你發(fā)現(xiàn)數(shù)據(jù)庫(kù)因?yàn)檫@兩個(gè)線程的原因而無(wú)法啟動(dòng)時(shí)，可以設(shè)置。

innodb_force_recovery = 3。除了設(shè)置2之后的操作不會(huì)運(yùn)行，undo回滾數(shù)據(jù)庫(kù)也不會(huì)進(jìn)行，但是回滾段依然會(huì)被掃描，undo鏈表也依然會(huì)被創(chuàng)建(trx_sys_init_at_db_start)。srv_read_only_mode會(huì)被打開(kāi)。

innodb_force_recovery = 4。除了設(shè)置3之后的操作不會(huì)運(yùn)行，ibuf的操作也不會(huì)運(yùn)行(ibuf_merge_or_delete_for_page)，表信息統(tǒng)計(jì)的線程也不會(huì)運(yùn)行(因?yàn)橐粋€(gè)壞的索引頁(yè)會(huì)導(dǎo)致數(shù)據(jù)庫(kù)崩潰)(info_low、dict_stats_update等)。從這個(gè)選項(xiàng)開(kāi)始，之后的所有選項(xiàng)，都會(huì)損壞數(shù)據(jù)，慎重使用。

innodb_force_recovery = 5。除了設(shè)置4之后的操作不會(huì)運(yùn)行，回滾段也不會(huì)被掃描(recv_recovery_rollback_active)，undo鏈表也不會(huì)被創(chuàng)建，這個(gè)主要用在undo日志被寫(xiě)壞的情況下。

innodb_force_recovery = 6。除了設(shè)置5之后的操作不會(huì)運(yùn)行，數(shù)據(jù)庫(kù)前滾操作也不會(huì)進(jìn)行，包括解析和應(yīng)用(recv_recovery_from_checkpoint_start_func)。

總結(jié)

InnoDB實(shí)現(xiàn)了一套完善的崩潰恢復(fù)機(jī)制，保證在任何狀態(tài)下(包括在崩潰恢復(fù)狀態(tài)下)數(shù)據(jù)庫(kù)掛了，都能正?；謴?fù)，這個(gè)是與文件系統(tǒng)比較大的差別。