- 概述
前面很多大俠都分享過MySQL的InnoDB存儲引擎將數(shù)據(jù)刷新的各種情況仰猖。我們這篇文章從InnoDB往下，看看數(shù)據(jù)從InnoDB的內(nèi)存到真正寫到存儲設(shè)備的介質(zhì)上到底有哪些緩沖在起作用。
我們通過下圖看一下相關(guān)的緩沖：
說明: Macintosh HD:Users:pickup112:Dropbox:woqutech:商務(wù)行政:990 old:擴(kuò)大影響力:mysql_caches:all_buffers.png
圖 1 innodb all buffers
從上圖中，我們可以看到，數(shù)據(jù)InnoDB到磁盤需要經(jīng)過
InnoDB buffer pool蠢沿， Redo log buffer。這個是InnoDB應(yīng)用系統(tǒng)本身的緩沖匾效。page cache /Buffer cache（可通過o_direct繞過）舷蟀。這個是vfs層的緩沖。Inode cache/directory buffer面哼。這個也是vfs層的緩沖雪侥。需要通過O_SYNC或者fsync()來刷新。Write-Back buffer精绎。(可設(shè)置存儲控制器參數(shù)繞過)Disk on-borad buffer。(可通過設(shè)置磁盤控制器參數(shù)繞過)
這里我們使用術(shù)語“緩沖”(一般為buffer)來表示對數(shù)據(jù)寫的暫存锌妻，使用術(shù)語“緩存”(一般為cache)來表示對數(shù)據(jù)讀的暫存代乃。顧名思義，由于底層存儲設(shè)備和內(nèi)存之間速率的差異，緩沖是用來暫“緩”對底層存儲設(shè)備IO的“沖”擊搁吓。緩存主要是在內(nèi)存中暫“存”從磁盤讀到的數(shù)據(jù)原茅，以便接下來對這些數(shù)據(jù)的訪問不用再次訪問慢速的底層存儲設(shè)備。
buffer和cache的討論可以參考彭立勛的：
http://www.penglixun.com/tech/system/buffer_and_cache_diff.html
下面我們對這些緩沖自頂向下逐一進(jìn)行詳細(xì)的介紹堕仔。
- INNODB層
該層的緩沖都放在主機(jī)內(nèi)存中擂橘，它的目的主要是在應(yīng)用層管理自己的數(shù)據(jù)，避免慢速的讀寫操作影響了InnoDB的響應(yīng)時間摩骨。
InnoDB層主要包括兩個buffer：redo log buffer和innodb buffer pool通贞。redo log buffer用來暫存對重做日志redo log的日志寫，InnoDB buffer pool存儲了從磁盤設(shè)備讀到的InnoDB數(shù)據(jù)恼五，也緩沖了對InnoDB數(shù)據(jù)寫昌罩，即臟頁數(shù)據(jù)。如果主機(jī)掉電或者M(jìn)ySQL異常宕機(jī)灾馒，innodb buffer pool將無法及時刷新到磁盤茎用，那么InnoDB就只能從上一個checkpoint使用redo log來前滾；而redo log buffer如果不能及時刷新到磁盤睬罗，那么由于redo log中數(shù)據(jù)的丟失轨功，就算使用redo 前滾，用戶提交的事務(wù)由于沒有真正的記錄到非易失型的磁盤介質(zhì)中容达，就丟失掉了古涧。
控制redo log buffer刷新時機(jī)的參數(shù)是innodb_flush_log_at_trx_commit，而控制redo log buffer和innodb buffer pool刷新方式的參數(shù)為innodb_flush_method董饰。針對這兩個參數(shù)詳細(xì)介紹的文章有非常多蒿褂，我們這里主要從緩沖的角度來解析。
2.1. INNODB_FLUSH_LOG_AT_TRX_COMMIT
控制redo log buffer的innodb_flush_log_at_trx_commit目前支持3種不同的參數(shù)值0卒暂，1啄栓，2
圖 2 innodb_flush_log_at_trx_commit示意圖
這里偷個懶，直接引用應(yīng)元的圖也祠。另外昙楚，更新一下innodb_flush_log_at_trx_commit=2時在5.6的變化：
< 5.6.6： 每隔一秒將redo log buffer中的數(shù)據(jù)刷新到磁盤
= 5.6.6：每隔innodb_flush_log_at_timeout秒將數(shù)據(jù)刷新到磁盤中去。
我們這里不再詳細(xì)討論這個問題诈嘿，具體細(xì)節(jié)可以參考MySQL數(shù)據(jù)丟失討論
2.2. INNODB_FLUSH_METHOD
控制innodb buffer pool的innodb_flush_method目前支持4種不同的參數(shù)值：
l fdatasync
l O_DSYNC
l O_DIRECT
l O_DIRECT_NO_FSYNC
這里我們注意到有幾個問題：
innodb_flush_method指定的不僅是“數(shù)據(jù)文件”的刷新方式堪旧，也指定了“日志文件”刷新方式。這些參數(shù)里面沒有在windows環(huán)境下的參數(shù)配置奖亚，現(xiàn)在大家都開始不鳥蓋茨兄了淳梦？其實(shí)在注釋里面寫了，windows就使用async_unbuffered昔字，并且不允許修改谭羔，所以沒有寫到列表里面。前三個參數(shù)值只允許在5.6.6和5.6.6之前的版本中用坏为，從5.6.7開始新增了O_DIRECT_NO_FSYNC。也就是說用O_DIRECT打開文件弦疮，但是不用fsync()同步數(shù)據(jù)。這個由于在較新的Linux內(nèi)核和部分文件系統(tǒng)中蜘醋，使用O_DIRECT就可以保證數(shù)據(jù)安全胁塞，不用專門再用fsync()來同步，保證元數(shù)據(jù)也刷新到非易失型的磁盤介質(zhì)压语。例如：XFS就不能用這個參數(shù)啸罢。O_DIRECT繞過了page cache，為什么還要用fsync()再刷新以下无蜂，我們在下節(jié)專門討論伺糠。有人會說referense文檔有個小bug，5.6.6之前的版本default是fdatasync斥季，但是Valid Values可指定的值內(nèi)竟然沒有fdatasync训桶。
表格 1 innodb_flush_method可選值
其實(shí)這里是他故意的，因?yàn)閒datasync()和fsync()是不一樣的酣倾，就像O_DSYNC和O_SYNC的區(qū)別一樣舵揭。Fdatasync和O_DSYNC僅用于數(shù)據(jù)同步，fsync()和O_SYNC用于數(shù)據(jù)和元數(shù)據(jù)meta-data同步躁锡。但是MySQL用fdatasync參數(shù)值來指明“數(shù)據(jù)文件”和“日志文件”是用fsync()打開的(注意：不是fdatasync())午绳，這個是歷史原因，所以5.6特意把它從可選值中去掉映之，避免誤解拦焚。當(dāng)然你如果仍然要使用fsync()來同步，那就對innodb_flush_method什么都不要指定就可以了杠输。
除了O_DIRECT_NO_FSYNC以外赎败，InnoDB都使用fsync()刷新“數(shù)據(jù)文件”。這里的異常就是O_DIRECT_NO_FSYNC蠢甲。如果指定O_DIRECT僵刮，O_DIRECT_NO_FSYNC，數(shù)據(jù)文件是以O(shè)_DIRECT打開(solaris上用directio()方式打開鹦牛，如果Innodb的數(shù)據(jù)文件都放在單獨(dú)的設(shè)備時搞糕，可以在mount 時使用forcedirectio使得整個文件系統(tǒng)都是以directio打開。這里指明為innodb而不是MySQL的原因是曼追，MyISAM不要用directio())
閑話少說窍仰，下面的一個表和一張圖能夠更加直觀的說明問題：
重新加工了orczhou的刷新關(guān)系表：
表格 2 innodb_flush_method數(shù)據(jù)文件和日志刷新對應(yīng)表
說明: Macintosh HD:Users:pickup112:Dropbox:woqutech:商務(wù)行政:990 old:擴(kuò)大影響力:mysql_caches:innodb_flush_method.png
圖 3 innodb_flush_method數(shù)據(jù)文件和日志刷新示意圖
- VFS層
該層的緩沖都放在主機(jī)內(nèi)存中，它的目的主要是在操作系統(tǒng)層緩沖數(shù)據(jù)礼殊，避免慢速塊設(shè)備讀寫操作影響了IO的響應(yīng)時間辈赋。
3.1. 細(xì)究O_DIRECT/O_SYNC標(biāo)簽
在前面redo log buffer和innodb buffer pool的討論中涉及到很多數(shù)據(jù)刷新和數(shù)據(jù)安全的問題鲫忍，我們在本節(jié)中，專門討論O_DIRECT/O_SYNC標(biāo)簽的含義钥屈。
我們打開一個文件并寫入數(shù)據(jù)，VFS和文件系統(tǒng)是怎么把數(shù)據(jù)寫到硬件層列坝辫，下圖展示了關(guān)鍵的數(shù)據(jù)結(jié)構(gòu)：
說明: Macintosh HD:Users:pickup112:Dropbox:woqutech:商務(wù)行政:990 old:擴(kuò)大影響力:mysql_caches:linux_caches.gif
圖 4 VFS cache圖
該圖引用自The linux kernel’s VFS Layer篷就。
圖中，我們看到該層中主要有page_cache/buffer cache/Inode-cache/Directory cache近忙。其中page_cache/buffer cache主要用于緩沖內(nèi)存結(jié)構(gòu)數(shù)據(jù)和塊設(shè)備數(shù)據(jù)竭业。而inode-cache用于緩沖inode，directory-cache用于緩沖目錄結(jié)構(gòu)數(shù)據(jù)及舍。
根據(jù)文件系統(tǒng)和操作系統(tǒng)的不同未辆，一般來說對一個文件的寫入操作包括兩部分，對數(shù)據(jù)本身的寫入操作锯玛，以及對文件屬性（metadata元數(shù)據(jù)）的寫入操作(這里的文件屬性包括目錄咐柜，inode等)。
了解了這些以后攘残，我們就能夠比較簡單的說清楚各個標(biāo)志的意義了：
表格 3 VFS cache刷新表
l O_DSYNC和fdatasync()的區(qū)別在于：是在每一個IO提交的時刻都針對對應(yīng)的page cache和buffer cache進(jìn)行刷新拙友；還是在一定數(shù)據(jù)的寫操作以后調(diào)用fdatasync()的時刻對整個page cache和buffer cache進(jìn)行刷新。O_SYNC和fsync()的區(qū)別同理歼郭。
l page cache和buffer cache的主要區(qū)別在于一個是面向?qū)嶋H文件數(shù)據(jù)遗契，一個是面向塊設(shè)備。在VFS上層使用open()方式打開那些使用mkfs做成文件系統(tǒng)的文件病曾，你就會用到page cache和buffer cache牍蜂，而如果你在Linux操作系統(tǒng)上使用dd這種方式來操作Linux的塊設(shè)備，你就只會用到buffer cache泰涂。
l O_DSYNC和O_SYNC的區(qū)別在于：O_DSYNC告訴內(nèi)核鲫竞，當(dāng)向文件寫入數(shù)據(jù)的時候，只有當(dāng)數(shù)據(jù)寫到了磁盤時负敏，寫入操作才算完成（write才返回成功）贡茅。O_SYNC比O_DSYNC更嚴(yán)格，不僅要求數(shù)據(jù)已經(jīng)寫到了磁盤其做，而且對應(yīng)的數(shù)據(jù)文件的屬性（例如文件inode顶考，相關(guān)的目錄變化等）也需要更新完成才算write操作成功⊙梗可見O_SYNC較之O_DSYNC要多做一些操作驹沿。
l Open()的referense中還有一個O_ASYNC，它主要用于terminals, pseudoterminals, sockets, 和pipes/FIFOs蹈胡，是信號驅(qū)動的IO渊季，當(dāng)設(shè)備可讀寫時發(fā)送一個信號（SIGIO）朋蔫，應(yīng)用進(jìn)程捕獲這個信號來進(jìn)行IO操作。
l O_SYNC和O_DIRECT都是同步寫却汉，也就是說只有寫成功了才會返回驯妄。
回過頭來，我們再來看innodb_flush_log_at_trx_commit的配置就比較好理解了合砂。O_DIRECT直接IO繞過了page cache/buffer cache以后為什么還需要fsync()了青扔，就是為了把directory cache和inode cache元數(shù)據(jù)也刷新到存儲設(shè)備上。
而由于內(nèi)核和文件系統(tǒng)的更新翩伪，有些文件系統(tǒng)能夠保證保證在O_DIRECT方式下不用fsync()同步元數(shù)據(jù)也不會導(dǎo)致數(shù)據(jù)安全性問題微猖，所以InnoDB又提供了O_DIRECT_NO_FSYNC的方式。
當(dāng)然缘屹，O_DIRECT對讀和對寫都是有效的凛剥，特別是對讀，它可以保證讀到的數(shù)據(jù)是從存儲設(shè)備中讀到的轻姿，而不是緩存中的犁珠。避免緩存中的數(shù)據(jù)和存儲設(shè)備上的數(shù)據(jù)是不一致的情況(比如你通過DRBD將底層塊設(shè)備的數(shù)據(jù)更新了，對于非分布式文件系統(tǒng)踢代，緩存中的內(nèi)容和存儲設(shè)備上的數(shù)據(jù)就不一致了)盲憎。但是我們這里主要討論緩沖(寫buffer)，就不深入討論了胳挎。這個問題了饼疙。
3.2. O_DIRECT優(yōu)劣勢
在大部分的innodb_flush_method參數(shù)值的推薦中都會建議使用O_DIRECT，甚至在percona server分支中還提供了ALL_O_DIRECT慕爬，對日志文件也使用了O_DIRECT方式打開窑眯。
3.2.1. 優(yōu)勢：
l 節(jié)省操作系統(tǒng)內(nèi)存：O_DIRECT直接繞過page cache/buffer cache，這樣避免InnoDB在讀寫數(shù)據(jù)少占用操作系統(tǒng)的內(nèi)存医窿，把更多的內(nèi)存留個innodb buffer pool來使用磅甩。
l 節(jié)省CPU。另外姥卢，內(nèi)存到存儲設(shè)備的傳輸方式主要有poll卷要，中斷和DMA方式。使用O_DIRECT方式提示操作系統(tǒng)盡量使用DMA方式來進(jìn)行存儲設(shè)備操作独榴，節(jié)省CPU僧叉。
3.2.2. 劣勢
l 字節(jié)對齊。O_DIRECT方式要求寫數(shù)據(jù)時棺榔，內(nèi)存是字節(jié)對齊的(對齊的方式根據(jù)內(nèi)核和文件系統(tǒng)的不同而不同)瓶堕。這就要求數(shù)據(jù)在寫的時候需要有額外的對齊操作≈⑿可以通過/sys/block/sda/queue/logical_block_size知道對齊的大小,一般都是512個字節(jié)郎笆。
l 無法進(jìn)行IO合并谭梗。O_DIRECT繞過page cache/buffer cache直接寫存儲設(shè)備，這樣如果對同一塊數(shù)據(jù)進(jìn)行重復(fù)寫就無法在內(nèi)存中命中宛蚓，page cache/buffer cache合并寫的功能就無法生效了激捏。
l 降低順序讀寫效率。如果使用O_DIRECT打開文件凄吏，則讀/寫操作都會跳過cache缩幸，直接在存儲設(shè)備上讀/寫。因?yàn)闆]有了cache竞思，所以文件的順序讀寫使用O_DIRECT這種小IO請求的方式效率是比較低的。
總的來說钞护，使用O_DIRECT來設(shè)置innodb_flush_method并不是100%對所有應(yīng)用和場景都是適用的盖喷。
- 存儲控制器層
該層的緩沖都放在存儲控制器的對應(yīng)板載cache中，它的目的主要是在存儲控制器層緩沖數(shù)據(jù)难咕，避免慢速塊設(shè)備讀寫操作影響了IO的響應(yīng)時間课梳。
當(dāng)數(shù)據(jù)被fsync()等刷到存儲層時，首先會發(fā)送到存儲控制器層余佃。常見的存儲控制器就是Raid卡暮刃，而目前大部分的Raid卡都有1G或者更大的存儲容量。這個緩沖一般為易失性的存儲爆土，通過板載電池/電容來保證該“易失性的存儲”的數(shù)據(jù)在機(jī)器斷電以后仍然會同步到底層的磁盤存儲介質(zhì)上椭懊。
關(guān)于存儲控制器我們有一些幾個方面需要注意的：
write back/write through：
針對是否使用緩沖，一般的存儲控制器都提供write back和write through兩種方式步势。write back方式下氧猬，操作系統(tǒng)提交的寫數(shù)據(jù)請求直接寫入到緩沖中就返回成功；write through方式下坏瘩，操作系統(tǒng)提交的寫數(shù)據(jù)請求必須要真正寫到底層磁盤介質(zhì)上才返回成功盅抚。
電池/電容區(qū)別：
為了保證機(jī)器掉電以后在“易失性”緩沖中的數(shù)據(jù)能夠及時刷新到底層磁盤介質(zhì)上，存儲控制器上都有電池/電容來保證倔矾。普通的電池有容量衰減的問題妄均，也就是說每隔一段時間，板載的電池都要被控制充放電一次哪自，以保證電池的容量丰包。在電池充放過程中，被設(shè)置為write-back的存儲控制器會自動變?yōu)閣rite through提陶。這個充放電的周期(Learn Cycle周期)一般為90天烫沙，LSI卡可以通過MegaCli來查看：
#MegaCli -AdpBbuCmd -GetBbuProperties-aAll
BBU Properties for Adapter: 0
Auto Learn Period: 90 Days
Next Learn time: Tue Oct 14 05:38:43 2014
Learn Delay Interval:0 Hours
Auto-Learn Mode: Enabled
如果你每隔一段時間發(fā)現(xiàn)IO請求響應(yīng)時間突然慢下來了，就有可能是這個問題哦隙笆。通過MegaCli -AdpEventLog -GetEvents -f mr_AdpEventLog.txt -aALL的日志中的Event Description: Battery started charging就可以確定是否發(fā)生了發(fā)生了充放電的情況锌蓄。
由于電池有這個問題升筏，新的Raid卡會配置電容來保證“易失性”緩沖中的數(shù)據(jù)能夠及時刷新到底層磁盤介質(zhì)上，這樣就沒有充放電的問題了瘸爽。
read/write ratio：
HP的smart array提供對cache的讀和寫的區(qū)別(Accelerator Ratio)您访，
hpacucli ctrl all show config detail|grep 'Accelerator Ratio'
Accelerator Ratio: 25% Read / 75% Write
這樣你就可以根據(jù)應(yīng)用的實(shí)際情況來設(shè)置用于緩存讀和緩沖寫的cache的比例了。
開啟Direct IO
為了能夠讓上層的設(shè)備使用Direct IO方式來繞過raid卡剪决，對Raid需要設(shè)置開啟DirectIO方式：
/opt/MegaRAID/MegaCli/MegaCli64 -LDSetProp -Direct -Immediate -Lall -aAll
LSI flash raid：
上面我們提到了“易失性”緩沖灵汪，如果我們現(xiàn)在有一個非易失性的緩沖，并且容量達(dá)到幾百G柑潦，這樣的存儲控制器緩沖是不是更能給底層設(shè)備提速享言？作為老牌的Raid卡廠商，LSI目前就有這樣的存儲控制器渗鬼，使用write back方式和比較依賴存儲控制器緩沖的應(yīng)用可以考慮使用這種類型的存儲控制器览露。
write barriers
目前raid卡的cache是否有電池或者電容保護(hù)對Linux來說是不可見的，所以Linux為了保證日志文件系統(tǒng)的一致性譬胎，默認(rèn)會打開write barriers差牛，也就是說，它會不斷的刷新“易失性”緩沖堰乔，這樣會大大降低IO性能偏化。所以如果你確信底層的電池能夠保證“易失性”緩沖會刷到底層磁盤設(shè)備的話，你可以在磁盤mount的時候加上-o nobarrier镐侯。
- 磁盤控制器層
該層的緩沖都放在磁盤控制器的對應(yīng)板載cache中侦讨。存儲設(shè)備固件(firmware)會按規(guī)則排序?qū)懖僮髡嬲降浇橘|(zhì)中去。這里主要是保證寫的順序性析孽，對機(jī)械磁盤來說搭伤，這樣可以盡量讓一次磁頭的移動能夠完成更多的磁碟寫入操作。
一般來說袜瞬，DMA控制器也是放在磁盤這一層的怜俐，通過DMA控制器直接進(jìn)行內(nèi)存訪問，能夠節(jié)省CPU的資源邓尤。
對于機(jī)械硬盤拍鲤，因?yàn)橐话愕拇疟P設(shè)備上并沒有電池電容等，無法保證在機(jī)器掉電時磁盤cache里面的所有數(shù)據(jù)能夠及時同步到介質(zhì)上汞扎，所以我們強(qiáng)烈建議把disk cache關(guān)閉掉季稳。
Disk cache可以在存儲控制器層關(guān)閉。例如澈魄，使用MegaCli關(guān)閉的命令如下：
MegaCli -LDSetProp -DisDskCache -Lall -aALL
- 總結(jié)
從InnoDB到最終的介質(zhì)景鼠，我們經(jīng)過了各種緩沖，他們的目的其實(shí)很明確，就是為了解決：內(nèi)存和磁盤的速度不匹配的問題铛漓，或者說是磁盤的速度過慢的問題溯香。
另外，其實(shí)最懂?dāng)?shù)據(jù)是否應(yīng)該緩沖/緩存的還是應(yīng)用本身浓恶，VFS玫坛，存儲控制器和磁盤只能通過延遲寫入(以便合并重復(fù)IO，使隨機(jī)寫變成順序?qū)?來緩解底層存儲設(shè)備慢速造成的響應(yīng)速度慢的問題包晰。所以數(shù)據(jù)庫類型的應(yīng)用都會來自己管理緩沖湿镀，然后盡量避免操作系統(tǒng)和底層設(shè)備的緩沖。
但是其實(shí)由于目前SSD固態(tài)硬盤和PCIe Flash卡的出現(xiàn)伐憾，內(nèi)存和磁盤之間的速度差異被大大縮減了勉痴，這些緩沖是否必要，軟硬件哪些可改進(jìn)的树肃，對軟硬件工程師的一大挑戰(zhàn)蚀腿。
參考：
http://www.codeproject.com/Articles/460057/HDD-FS-O_SYNC-Throughput-vs-Integrity
http://rdc.taobao.com/blog/dba/html/296_innodb_flush_method_performance.html
http://www.orczhou.com/index.php/2009/08/innodb_flush_method-file-io/
http://blog.csdn.net/yuyin86/article/details/8113305
http://www.mtop.cc/node/100
https://www.usenix.org/legacy/event/usenix01/full_papers/kroeger/kroeger_html/node8.html
http://www.lsi.com/downloads/Public/Direct%20Assets/LSI/Benchmark_Tips.pdf
http://www.lsi.com/products/flash-accelerators/pages/default.aspx。
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/writebarrieronoff.html
http://en.wikipedia.org/wiki/Direct_memory_access
http://www.hgst.com/tech/techlib.nsf/techdocs/DFE76984029D3BE586256FAB0058B1A8/$file/DMA-white_paper_FINAL.pdf
http://en.wikipedia.org/wiki/Disk_buffer
- 附錄
7.1. O_DIRECT的方式的PYTHON CODE
錯誤的方式:
import os
f = os.open('file', os.O_CREAT | os.O_TRUNC | os.O_DIRECT | os.O_RDWR)
s = ' ' * 1024
os.write(f, s)
Traceback (most recent call last):
File "", line 1, in
OSError: [Errno 22] Invalid argument
正確的方式:
import os
import mmap
f = os.open('file', os.O_CREAT | os.O_DIRECT | os.O_TRUNC | os.O_RDWR)
m = mmap.mmap(-1, 1024 * 1024)
s = ' ' * 1024 * 1024
m.write(s)
os.write(f, m)
os.close(f)
