MySQL探秘(四):InnoDB的磁盘文件及落盘机制(持久性)
任何一個(gè)技術(shù)都有其底層的關(guān)鍵基礎(chǔ)技術(shù),這些關(guān)鍵技術(shù)很有可能也是其他技術(shù)的關(guān)鍵技術(shù),學(xué)習(xí)這些底層技術(shù),就可以一通百通,讓你很快的掌握其他技術(shù)。如何在磁盤上存儲(chǔ)數(shù)據(jù),如何使用日志文件保證數(shù)據(jù)不丟失以及如何落盤,不僅是MySQL等數(shù)據(jù)庫的關(guān)鍵技術(shù),也是MQ消息隊(duì)列或者其他中間件的關(guān)鍵技術(shù)之一。
上圖詳細(xì)顯示了InnoDB存儲(chǔ)引擎的體系架構(gòu),從圖中可見,InnoDB存儲(chǔ)引擎由內(nèi)存池,后臺(tái)線程和磁盤文件三大部分組成。接下來我們就來簡(jiǎn)單了解一下磁盤文件相關(guān)的概念和原理。
InnoDB的主要的磁盤文件主要分為三大塊:一是系統(tǒng)表空間,二是用戶表空間,三是redo日志文件和歸檔文件。二進(jìn)制文件(binlog)等文件是MySQL Server層維護(hù)的文件,所以未列入InnoDB的磁盤文件中。
系統(tǒng)表空間和用戶表空間
InnoDB系統(tǒng)表空間包含InnoDB數(shù)據(jù)字典(元數(shù)據(jù)以及相關(guān)對(duì)象)并且doublewrite buffer,change buffer,undo logs的存儲(chǔ)區(qū)域。系統(tǒng)表空間也默認(rèn)包含任何用戶在系統(tǒng)表空間創(chuàng)建的表數(shù)據(jù)和索引數(shù)據(jù)。系統(tǒng)表空間是一個(gè)共享的表空間因?yàn)樗潜欢鄠€(gè)表共享的
系統(tǒng)表空間是由一個(gè)或者多個(gè)數(shù)據(jù)文件組成。默認(rèn)情況下,1個(gè)初始大小為10MB,名為ibdata1的系統(tǒng)數(shù)據(jù)文件在MySQL的data目錄下被創(chuàng)建。用戶可以使用innodb_data_file_path對(duì)數(shù)據(jù)文件的大小和數(shù)量進(jìn)行配置。
innodbdatafile_path的格式如下:
innodb_data_file_path=datafile1[,datafile2]...用戶可以通過多個(gè)文件組成一個(gè)表空間,同時(shí)制定文件的屬性:
innodb_data_file_path = /db/ibdata1:1000M;/dr2/db/ibdata2:1000M:autoextend這里講/db/ibdata1和/dr2/db/ibdata2兩個(gè)文件組成系統(tǒng)表空間。如果這兩個(gè)文件位于不同的磁盤上,磁盤的負(fù)載可能被平均,因此可以提高數(shù)據(jù)庫的整體性能。兩個(gè)文件的文件名之后都跟了屬性,表示文件ibdata1的大小為1000MB,文件ibdata2的大小為1000MB,而且用完空間之后可以自動(dòng)增長(zhǎng)(autoextend)。
設(shè)置innodbdatafilepath參數(shù)之后,所以基于InnoDB存儲(chǔ)引擎的表的數(shù)據(jù)都會(huì)記錄到該系統(tǒng)表空間中,如果設(shè)置了參數(shù)innodbfilepertable,則用戶可以將每個(gè)基于InnoDB存儲(chǔ)引擎的表產(chǎn)生一個(gè)獨(dú)立的用戶表空間。用戶表空間的命名規(guī)則為:表名.ibd。
通過這種方式,用戶不用將所有數(shù)據(jù)都存放于默認(rèn)的系統(tǒng)表空間中,但是用戶表空只存儲(chǔ)該表的數(shù)據(jù)、索引和插入緩沖BITMAP等信息,其余信息還是存放在默認(rèn)的表空間中。
上圖顯示InnoDB存儲(chǔ)引擎對(duì)于文件的存儲(chǔ)方式,其中frm文件是表結(jié)構(gòu)定義文件,記錄每個(gè)表的表結(jié)構(gòu)定義。
重做日志文件和歸檔文件
默認(rèn)情況下,在InnoDB存儲(chǔ)引擎的數(shù)據(jù)目錄下會(huì)有兩個(gè)名為iblogfile0和iblogfile1的文件,這就是InnoDB的重做日志文件(redo log file),它記錄了對(duì)于InnoDB存儲(chǔ)引擎的事務(wù)日志。 當(dāng)InnoDB的數(shù)據(jù)存儲(chǔ)文件發(fā)生錯(cuò)誤時(shí),重做日志文件就能派上用場(chǎng)。InnoDB存儲(chǔ)引擎可以使用重做日志文件將數(shù)據(jù)恢復(fù)為正確狀態(tài),以此來保證數(shù)據(jù)的正確性和完整性。
每個(gè)InnoDB存儲(chǔ)引擎至少有1個(gè)重做日志文件組(group),每個(gè)文件組下至少有2個(gè)重做日志文件,如默認(rèn)的iblogfile0和iblogfile1。
為了得到更高的可靠性,用戶可以設(shè)置多個(gè)鏡像日志組,將不同的文件組放在不同的磁盤上,以此來提高重做日志的高可用性。
在日志組中每個(gè)重做日志文件的大小一致,并以循環(huán)寫入的方式運(yùn)行。InnoDB存儲(chǔ)引擎先寫入重做日志文件1,當(dāng)文件被寫滿時(shí),會(huì)切換到重做日志文件2,再當(dāng)重做日志文件2也被寫滿時(shí),再切換到重做日志文件1。
用戶可以使用innodb_log_file_size來設(shè)置重做日志文件的大小,這對(duì)InnoDB存儲(chǔ)引擎的性能有著非常大的影響。默認(rèn)8MB。
如果重做日志文件設(shè)置的太大,數(shù)據(jù)丟失時(shí),恢復(fù)時(shí)可能需要很長(zhǎng)的時(shí)間;另一方面,如果設(shè)置的太小,重做日志文件太小會(huì)導(dǎo)致依據(jù)checkpoint的檢查需要頻繁刷新臟頁到磁盤中,導(dǎo)致性能的抖動(dòng)。
重做日志相關(guān)和Checkpoint的機(jī)制可以閱讀之前文章的相應(yīng)章節(jié)。
MySQL探秘(三):InnoDB的內(nèi)存結(jié)構(gòu)和特性
重做日志的落盤機(jī)制
InnoDB對(duì)于數(shù)據(jù)文件和日志文件的刷盤遵守WAL(Write ahead redo log) 和Force-log-at-commit兩種規(guī)則,二者保證了事務(wù)的持久性。WAL要求數(shù)據(jù)的變更寫入到磁盤前,首先必須將內(nèi)存中的重做日志寫入到磁盤;Force-log-at-commit要求當(dāng)一個(gè)事務(wù)提交時(shí),所有產(chǎn)生的重做日志都必須刷新到磁盤上,如果日志刷新成功后,緩沖池中的數(shù)據(jù)刷新到磁盤前數(shù)據(jù)庫發(fā)生了宕機(jī),那么重啟時(shí),數(shù)據(jù)庫可以從重做日志中恢復(fù)數(shù)據(jù)。
如上圖所示,InnoDB在緩沖池中變更數(shù)據(jù)時(shí),會(huì)首先將相關(guān)變更寫入重做日志緩沖中,然后再按時(shí)或者當(dāng)事務(wù)提交時(shí)寫入磁盤,這符合Force-log-at-commit原則;當(dāng)重做日志寫入磁盤后,緩沖池中的變更數(shù)據(jù)才會(huì)依據(jù)checkpoint機(jī)制擇時(shí)寫入到磁盤中,這符合WAL原則。 在checkpoint擇時(shí)機(jī)制中,就有重做日志文件寫滿的判斷,所以,如前文所述,如果重做日志文件太小,經(jīng)常被寫滿,就會(huì)頻繁導(dǎo)致checkpoint將更改的數(shù)據(jù)寫入磁盤,導(dǎo)致性能抖動(dòng)。
操作系統(tǒng)的文件系統(tǒng)是帶有緩存的,當(dāng)InnoDB向磁盤寫入數(shù)據(jù)時(shí),有可能只是寫入到了文件系統(tǒng)的緩存中,沒有真正的“落袋為安”。
InnoDB的innodb_flush_log_at_trx_commit屬性可以控制每次事務(wù)提交時(shí)InnoDB的行為。當(dāng)屬性值為0時(shí),事務(wù)提交時(shí),不會(huì)對(duì)重做日志進(jìn)行寫入操作,而是等待主線程按時(shí)寫入;當(dāng)屬性值為1時(shí),事務(wù)提交時(shí),會(huì)將重做日志寫入文件系統(tǒng)緩存,并且調(diào)用文件系統(tǒng)的fsync,將文件系統(tǒng)緩沖中的數(shù)據(jù)真正寫入磁盤存儲(chǔ),確保不會(huì)出現(xiàn)數(shù)據(jù)丟失;當(dāng)屬性值為2時(shí),事務(wù)提交時(shí),也會(huì)將日志文件寫入文件系統(tǒng)緩存,但是不會(huì)調(diào)用fsync,而是讓文件系統(tǒng)自己去判斷何時(shí)將緩存寫入磁盤。日志的刷盤機(jī)制如下圖所示。
innodb_flush_log_at_trx_commit是InnoDB性能調(diào)優(yōu)的一個(gè)基礎(chǔ)參數(shù),涉及InnoDB的寫入效率和數(shù)據(jù)安全。當(dāng)參數(shù)值為0時(shí),寫入效率最高,但是數(shù)據(jù)安全最低;參數(shù)值為1時(shí),寫入效率最低,但是數(shù)據(jù)安全最高;參數(shù)值為2時(shí),二者都是中等水平。一般建議將該屬性值設(shè)置為1,以獲得較高的數(shù)據(jù)安全性,而且也只有設(shè)置為1,才能保證事務(wù)的持久性。
與50位技術(shù)專家面對(duì)面20年技術(shù)見證,附贈(zèng)技術(shù)全景圖總結(jié)
以上是生活随笔為你收集整理的MySQL探秘(四):InnoDB的磁盘文件及落盘机制(持久性)的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: MySQL探秘(三):InnoDB的内存
- 下一篇: MySQL探秘(五):InnoDB锁的类