超詳細的MySQL數(shù)據(jù)庫InnoDB崩潰恢復(fù)機制總結(jié)
概述
數(shù)據(jù)庫系統(tǒng)與文件系統(tǒng)大的區(qū)別在于數(shù)據(jù)庫能保證操作的原子性,一個操作要么不做要么都做,即使在數(shù)據(jù)庫宕機的情況下,也不會出現(xiàn)操作一半的情況,這個就需要數(shù)據(jù)庫的日志和一套完善的崩潰恢復(fù)機制來保證。下面簡單介紹一下InnoDB的崩潰恢復(fù)流程。
相關(guān)概念
lsn: 可以理解為數(shù)據(jù)庫從創(chuàng)建以來產(chǎn)生的redo日志量,這個值越大,說明數(shù)據(jù)庫的更新越多,也可以理解為更新的時刻。此外,每個數(shù)據(jù)頁上也有一個lsn,表示最后被修改時的lsn,值越大表示越晚被修改。比如,數(shù)據(jù)頁A的lsn為100,數(shù)據(jù)頁B的lsn為200,checkpoint lsn為150,系統(tǒng)lsn為300,表示當前系統(tǒng)已經(jīng)更新到300,小于150的數(shù)據(jù)頁已經(jīng)被刷到磁盤上,因此數(shù)據(jù)頁A的最新數(shù)據(jù)一定在磁盤上,而數(shù)據(jù)頁B則不一定,有可能還在內(nèi)存中。
redo日志: 現(xiàn)代數(shù)據(jù)庫都需要寫redo日志,例如修改一條數(shù)據(jù),首先寫redo日志,然后再寫數(shù)據(jù)。在寫完redo日志后,就直接給客戶端返回成功。這樣雖然看過去多寫了一次盤,但是由于把對磁盤的隨機寫入(寫數(shù)據(jù))轉(zhuǎn)換成了順序的寫入(寫redo日志),性能有很大幅度的提高。當數(shù)據(jù)庫掛了之后,通過掃描redo日志,就能找出那些沒有刷盤的數(shù)據(jù)頁(在崩潰之前可能數(shù)據(jù)頁僅僅在內(nèi)存中修改了,但是還沒來得及寫盤),保證數(shù)據(jù)不丟。
undo日志: 數(shù)據(jù)庫還提供類似撤銷的功能,當你發(fā)現(xiàn)修改錯一些數(shù)據(jù)時,可以使用rollback指令回滾之前的操作。這個功能需要undo日志來支持。此外,現(xiàn)代的關(guān)系型數(shù)據(jù)庫為了提高并發(fā)(同一條記錄,不同線程的讀取不沖突,讀寫和寫讀不沖突,只有同時寫才沖突),都實現(xiàn)了類似MVCC的機制,在InnoDB中,這個也依賴undo日志。為了實現(xiàn)統(tǒng)一的管理,與redo日志不同,undo日志在Buffer Pool中有對應(yīng)的數(shù)據(jù)頁,與普通的數(shù)據(jù)頁一起管理,依據(jù)LRU規(guī)則也會被淘汰出內(nèi)存,后續(xù)再從磁盤讀取。與普通的數(shù)據(jù)頁一樣,對undo頁的修改,也需要先寫redo日志。
檢查點: 英文名為checkpoint。數(shù)據(jù)庫為了提高性能,數(shù)據(jù)頁在內(nèi)存修改后并不是每次都會刷到磁盤上。checkpoint之前的數(shù)據(jù)頁保證一定落盤了,這樣之前的日志就沒有用了(由于InnoDB redolog日志循環(huán)使用,這時這部分日志就可以被覆蓋),checkpoint之后的數(shù)據(jù)頁有可能落盤,也有可能沒有落盤,所以checkpoint之后的日志在崩潰恢復(fù)的時候還是需要被使用的。InnoDB會依據(jù)臟頁的刷新情況,定期推進checkpoint,從而減少數(shù)據(jù)庫崩潰恢復(fù)的時間。檢查點的信息在第一個日志文件的頭部。
崩潰恢復(fù): 用戶修改了數(shù)據(jù),并且收到了成功的消息,然而對數(shù)據(jù)庫來說,可能這個時候修改后的數(shù)據(jù)還沒有落盤,如果這時候數(shù)據(jù)庫掛了,重啟后,數(shù)據(jù)庫需要從日志中把這些修改后的數(shù)據(jù)給撈出來,重新寫入磁盤,保證用戶的數(shù)據(jù)不丟。這個從日志中撈數(shù)據(jù)的過程就是崩潰恢復(fù)的主要任務(wù),也可以成為數(shù)據(jù)庫前滾。當然,在崩潰恢復(fù)中還需要回滾沒有提交的事務(wù),提交沒有提交成功的事務(wù)。由于回滾操作需要undo日志的支持,undo日志的完整性和可靠性需要redo日志來保證,所以崩潰恢復(fù)先做redo前滾,然后做undo回滾。
數(shù)據(jù)庫崩潰恢復(fù)過程
下面看一下數(shù)據(jù)庫崩潰恢復(fù)過程。整個過程都在引擎初始化階段完成(innobase_init),其中最主要的函數(shù)是innobase_start_or_create_for_mysql,innodb通過這個函數(shù)完成創(chuàng)建和初始化,包括崩潰恢復(fù)。首先來介紹一下數(shù)據(jù)庫的前滾。

崩潰恢復(fù)相關(guān)參數(shù)解析
1、innodb_fast_shutdown:
innodb_fast_shutdown = 0。這個表示在MySQL關(guān)閉的時候,執(zhí)行slow shutdown,不但包括日志的刷盤,數(shù)據(jù)頁的刷盤,還包括數(shù)據(jù)的清理(purge),ibuf的合并,buffer pool dump以及l(fā)azy table drop操作(如果表上有未完成的操作,即使執(zhí)行了drop table且返回成功了,表也不一定立刻被刪除)。 innodb_fast_shutdown = 1。這個是默認值,表示在MySQL關(guān)閉的時候,僅僅把日志和數(shù)據(jù)刷盤。 innodb_fast_shutdown = 2。這個表示關(guān)閉的時候,僅僅日志刷盤,其他什么都不做,就好像MySQL crash了一樣。 這個參數(shù)值越大,MySQL關(guān)閉的速度越快,但是啟動速度越慢,相當于把關(guān)閉時候需要做的工作挪到了崩潰恢復(fù)上。另外,如果MySQL要升級,建議使用第一種方式進行一次干凈的shutdown。
2、innodb_force_recovery
這個參數(shù)主要用來控制InnoDB啟動時候做哪些工作,數(shù)值越大,做的工作越少,啟動也更加容易,但是數(shù)據(jù)不一致的風(fēng)險也越大。當MySQL因為某些不可控的原因不能啟動時,可以設(shè)置這個參數(shù),從1開始逐步遞增,知道MySQL啟動,然后使用SELECT INTO OUTFILE把數(shù)據(jù)導(dǎo)出,盡最大的努力減少數(shù)據(jù)丟失。 innodb_force_recovery = 0。這個是默認的參數(shù),啟動的時候會做所有的事情,包括redo日志應(yīng)用,undo日志回滾,啟動后臺master和purge線程,ibuf合并。檢測到了數(shù)據(jù)頁損壞了,如果是系統(tǒng)表空間的,則會crash,用戶表空間的,則打錯誤日志。
innodb_force_recovery = 1。如果檢測到數(shù)據(jù)頁損壞了,不會crash也不會報錯(buf_page_io_complete),啟動的時候也不會校驗表空間第一個數(shù)據(jù)頁的正確性(fil_check_first_page),表空間無法訪問也繼續(xù)做崩潰恢復(fù)(fil_open_single_table_tablespace、fil_load_single_table_tablespace),ddl操作不能進行(check_if_supported_inplace_alter),同時數(shù)據(jù)庫也被不能進行寫入操作(row_insert_for_mysql、row_update_for_mysql等),所有的prepare事務(wù)也會被回滾(trx_resurrect_insert、trx_resurrect_update_in_prepared_state)。這個選項還是很常用的,數(shù)據(jù)頁可能是因為磁盤壞了而損壞了,設(shè)置為1,能保證數(shù)據(jù)庫正常啟動。 innodb_force_recovery = 2。除了設(shè)置1之后的操作不會運行,后臺的master和purge線程就不會啟動了(srv_master_thread、srv_purge_coordinator_thread等),當你發(fā)現(xiàn)數(shù)據(jù)庫因為這兩個線程的原因而無法啟動時,可以設(shè)置。
innodb_force_recovery = 3。除了設(shè)置2之后的操作不會運行,undo回滾數(shù)據(jù)庫也不會進行,但是回滾段依然會被掃描,undo鏈表也依然會被創(chuàng)建(trx_sys_init_at_db_start)。srv_read_only_mode會被打開。
innodb_force_recovery = 4。除了設(shè)置3之后的操作不會運行,ibuf的操作也不會運行(ibuf_merge_or_delete_for_page),表信息統(tǒng)計的線程也不會運行(因為一個壞的索引頁會導(dǎo)致數(shù)據(jù)庫崩潰)(info_low、dict_stats_update等)。從這個選項開始,之后的所有選項,都會損壞數(shù)據(jù),慎重使用。
innodb_force_recovery = 5。除了設(shè)置4之后的操作不會運行,回滾段也不會被掃描(recv_recovery_rollback_active),undo鏈表也不會被創(chuàng)建,這個主要用在undo日志被寫壞的情況下。
innodb_force_recovery = 6。除了設(shè)置5之后的操作不會運行,數(shù)據(jù)庫前滾操作也不會進行,包括解析和應(yīng)用(recv_recovery_from_checkpoint_start_func)。
總結(jié)
InnoDB實現(xiàn)了一套完善的崩潰恢復(fù)機制,保證在任何狀態(tài)下(包括在崩潰恢復(fù)狀態(tài)下)數(shù)據(jù)庫掛了,都能正常恢復(fù),這個是與文件系統(tǒng)最大的差別。