1.? 概述

前面很多大俠都分享過MySQL的InnoDB存儲引擎將數據刷新的各種情況。我們這篇文章從InnoDB往下，看看數據從InnoDB的內存到真正寫到存儲設備的介質上到底有哪些緩沖在起作用。

我們通過下圖看一下相關的緩沖：

圖 1 innodb all buffers

從上圖中，我們可以看到，數據InnoDB到磁盤需要經過

InnoDB buffer pool， Redo log buffer。這個是InnoDB應用系統本身的緩沖。

page cache /Buffer cache(可通過o_direct繞過)。這個是vfs層的緩沖。

Inode cache/directory buffer。這個也是vfs層的緩沖。需要通過O_SYNC或者fsync()來刷新。

Write-Back buffer。(可設置存儲控制器參數繞過)

Disk on-borad buffer。(可通過設置磁盤控制器參數繞過)

這里我們使用術語“緩沖”(一般為buffer)來表示對數據寫的暫存，使用術語“緩存”(一般為cache)來表示對數據讀的暫存。顧名思義，由于底層存儲設備和內存之間速率的差異，緩沖是用來暫“緩”對底層存儲設備IO的“沖”擊。緩存主要是在內存中暫“存”從磁盤讀到的數據，以便接下來對這些數據的訪問不用再次訪問慢速的底層存儲設備。

buffer和cache的討論可以參考彭立勛的：

下面我們對這些緩沖自頂向下逐一進行詳細的介紹。

2.? InnoDB層

該層的緩沖都放在主機內存中，它的目的主要是在應用層管理自己的數據，避免慢速的讀寫操作影響了InnoDB的響應時間。

InnoDB層主要包括兩個buffer：redo log buffer和innodb buffer pool。redo log buffer用來暫存對重做日志redo log的日志寫，InnoDB buffer pool存儲了從磁盤設備讀到的InnoDB數據，也緩沖了對InnoDB數據寫，即臟頁數據。如果主機掉電或者MySQL異常宕機，innodb buffer pool將無法及時刷新到磁盤，那么InnoDB就只能從上一個checkpoint使用redo log來前滾；而redo log buffer如果不能及時刷新到磁盤，那么由于redo log中數據的丟失，就算使用redo 前滾，用戶提交的事務由于沒有真正的記錄到非易失型的磁盤介質中，就丟失掉了。

控制redo log buffer刷新時機的參數是innodb_flush_log_at_trx_commit，而控制redo log buffer和innodb buffer pool刷新方式的參數為innodb_flush_method。針對這兩個參數詳細介紹的文章有非常多，我們這里主要從緩沖的角度來解析。

2.1. innodb_flush_log_at_trx_commit

控制redo log buffer的innodb_flush_log_at_trx_commit目前支持3種不同的參數值0，1，2

圖 2 innodb_flush_log_at_trx_commit示意圖

這里偷個懶，直接引用應元的圖。另外，更新一下innodb_flush_log_at_trx_commit=2時在5.6的變化：

< 5.6.6： 每隔一秒將redo log buffer中的數據刷新到磁盤

= 5.6.6：每隔innodb_flush_log_at_timeout秒將數據刷新到磁盤中去。

我們這里不再詳細討論這個問題，具體細節可以參考MySQL數據丟失討論

2.2. innodb_flush_method

控制innodb buffer pool的innodb_flush_method目前支持4種不同的參數值：

fdatasync

O_DSYNC

O_DIRECT

O_DIRECT_NO_FSYNC

這里我們注意到有幾個問題：

innodb_flush_method指定的不僅是“數據文件”的刷新方式，也指定了“日志文件”刷新方式。

這些參數里面沒有在windows環境下的參數配置，現在大家都開始不鳥蓋茨兄了？其實在注釋里面寫了，windows就使用async_unbuffered，并且不允許修改，所以沒有寫到列表里面。

前三個參數值只允許在6.6和5.6.6之前的版本中用，從5.6.7開始新增了O_DIRECT_NO_FSYNC。也就是說用O_DIRECT打開文件，但是不用fsync()同步數據。這個由于在較新的Linux內核和部分文件系統中，使用O_DIRECT就可以保證數據安全，不用專門再用fsync()來同步，保證元數據也刷新到非易失型的磁盤介質。例如：XFS就不能用這個參數。O_DIRECT繞過了page cache，為什么還要用fsync()再刷新以下，我們在下節專門討論。

有人會說referense文檔有個小bug，6.6之前的版本default是fdatasync，但是Valid Values可指定的值內竟然沒有fdatasync。

System Variable Name

Variable Scope

Global

Dynamic Variable

No

Permitted Values (<= 5.6.6)

Type?(Linux)

string

Default

fdatasync

Valid Values

O_DSYNC

O_DIRECT

表格 1 innodb_flush_method可選值

其實這里是他故意的，因為fdatasync()和fsync()是不一樣的，就像O_DSYNC和O_SYNC的區別一樣。Fdatasync和O_DSYNC僅用于數據同步，fsync()和O_SYNC用于數據和元數據meta-data同步。但是MySQL用fdatasync參數值來指明“數據文件”和“日志文件”是用fsync()打開的(注意：不是fdatasync())，這個是歷史原因，所以5.6特意把它從可選值中去掉，避免誤解。當然你如果仍然要使用fsync()來同步，那就對innodb_flush_method什么都不要指定就可以了。

除了O_DIRECT_NO_FSYNC以外，InnoDB都使用fsync()刷新“數據文件”。這里的異常就是O_DIRECT_NO_FSYNC。

如果指定O_DIRECT，O_DIRECT_NO_FSYNC，數據文件是以O_DIRECT打開(solaris上用directio()方式打開，如果Innodb的數據文件都放在單獨的設備時，可以在mount 時使用forcedirectio使得整個文件系統都是以directio打開。這里指明為innodb而不是MySQL的原因是，MyISAM不要用directio())

對O_DIRECT_NO_FSYNC模式下日志文件是否可以用O_DIRECT方式打開的，我們特地找到mysql 5.6.14的storage/innobase/os/os0file.cc文件的os_file_create_func函數，摘錄代碼如下：

#ifdef UNIV_NON_BUFFERED_IO

// TODO: Create a bug, this looks wrong. The flush log

// parameter is dynamic.

if (type == OS_LOG_FILE && srv_flush_log_at_trx_commit == 2) {

/* Do not use unbuffered i/o for the log files because

value 2 denotes that we do not flush the log at every

commit, but only once per second */

} else if (srv_win_file_flush_method == SRV_WIN_IO_UNBUFFERED) {

attributes |= FILE_FLAG_NO_BUFFERING;

}

#endif /* UNIV_NON_BUFFERED_IO */

也就是說，對于日志文件來說，如果設置innodb_flush_log_at_trx_commit為2，O_DIRECT是無效的。

閑話少說，下面的一個表和一張圖能夠更加直觀的說明問題：

重新加工了orczhou的刷新關系表：

Open log

Flush log

flush log

Open datafile

flush datafile

fdatasync

fsync()

fsync()

O_DSYNC

O_SYNC

fsync()

O_DIRECT

fsync()

O_DIRECT

fsync()

O_DIRECT_NO_FSYNC

fsync()

O_DIRECT

All_O_DIRECT(percona)

O_DIRECT

fsync()

O_DIRECT

fsync

表格 2 innodb_flush_method數據文件和日志刷新對應表

圖 3 innodb_flush_method數據文件和日志刷新示意圖

3.? VFS層

該層的緩沖都放在主機內存中，它的目的主要是在操作系統層緩沖數據，避免慢速塊設備讀寫操作影響了IO的響應時間。

3.1. 細究O_DIRECT/O_SYNC標簽

在前面redo log buffer和innodb buffer pool的討論中涉及到很多數據刷新和數據安全的問題，我們在本節中，專門討論O_DIRECT/O_SYNC標簽的含義。

我們打開一個文件并寫入數據，VFS和文件系統是怎么把數據寫到硬件層列，下圖展示了關鍵的數據結構：

圖 4 VFS cache圖

圖中，我們看到該層中主要有page_cache/buffer cache/Inode-cache/Directory cache。其中page_cache/buffer cache主要用于緩沖內存結構數據和塊設備數據。而inode-cache用于緩沖inode，directory-cache用于緩沖目錄結構數據。

根據文件系統和操作系統的不同，一般來說對一個文件的寫入操作包括兩部分，對數據本身的寫入操作，以及對文件屬性(metadata元數據)的寫入操作(這里的文件屬性包括目錄，inode等)。

了解了這些以后，我們就能夠比較簡單的說清楚各個標志的意義了：

page cache

buffer cache

inode cache

dictory cache

O_DIRECT

write bypass

write bypass

write & no flush

write & no flush

O_DSYNC/fdatasync()

write & flush

write & flush

write & no flush

write & no flush

O_SYNC/fsync()

write & flush

write & flush

write & flush

write & flush

表格 3 VFS cache刷新表

O_DSYNC和fdatasync()的區別在于：是在每一個IO提交的時刻都針對對應的page cache和buffer cache進行刷新；還是在一定數據的寫操作以后調用fdatasync()的時刻對整個page cache和buffer cache進行刷新。O_SYNC和fsync()的區別同理。

page cache和buffer cache的主要區別在于一個是面向實際文件數據，一個是面向塊設備。在VFS上層使用open()方式打開那些使用mkfs做成文件系統的文件，你就會用到page cache和buffer cache，而如果你在Linux操作系統上使用dd這種方式來操作Linux的塊設備，你就只會用到buffer cache。

O_DSYNC和O_SYNC的區別在于：O_DSYNC告訴內核，當向文件寫入數據的時候，只有當數據寫到了磁盤時，寫入操作才算完成(write才返回成功)。O_SYNC比O_DSYNC更嚴格，不僅要求數據已經寫到了磁盤，而且對應的數據文件的屬性(例如文件inode，相關的目錄變化等)也需要更新完成才算write操作成功?？梢奜_SYNC較之O_DSYNC要多做一些操作。

Open()的referense中還有一個O_ASYNC，它主要用于terminals, pseudoterminals, sockets, 和pipes/FIFOs，是信號驅動的IO，當設備可讀寫時發送一個信號(SIGIO)，應用進程捕獲這個信號來進行IO操作。

O_SYNC和O_DIRECT都是同步寫，也就是說只有寫成功了才會返回。

回過頭來，我們再來看innodb_flush_log_at_trx_commit的配置就比較好理解了。O_DIRECT直接IO繞過了page cache/buffer cache以后為什么還需要fsync()了，就是為了把directory cache和inode cache元數據也刷新到存儲設備上。

而由于內核和文件系統的更新，有些文件系統能夠保證保證在O_DIRECT方式下不用fsync()同步元數據也不會導致數據安全性問題，所以InnoDB又提供了O_DIRECT_NO_FSYNC的方式。

當然，O_DIRECT對讀和對寫都是有效的，特別是對讀，它可以保證讀到的數據是從存儲設備中讀到的，而不是緩存中的。避免緩存中的數據和存儲設備上的數據是不一致的情況(比如你通過DRBD將底層塊設備的數據更新了，對于非分布式文件系統，緩存中的內容和存儲設備上的數據就不一致了)。但是我們這里主要討論緩沖(寫buffer)，就不深入討論了。這個問題了。

3.2. O_DIRECT優劣勢

在大部分的innodb_flush_method參數值的推薦中都會建議使用O_DIRECT，甚至在percona server分支中還提供了ALL_O_DIRECT，對日志文件也使用了O_DIRECT方式打開。

3.2.1.?? 優勢：

節省操作系統內存：O_DIRECT直接繞過page cache/buffer cache，這樣避免InnoDB在讀寫數據少占用操作系統的內存，把更多的內存留個innodb buffer pool來使用。

節省CPU。另外，內存到存儲設備的傳輸方式主要有poll，中斷和DMA方式。使用O_DIRECT方式提示操作系統盡量使用DMA方式來進行存儲設備操作，節省CPU。

3.2.2.?? 劣勢

字節對齊。O_DIRECT方式要求寫數據時，內存是字節對齊的(對齊的方式根據內核和文件系統的不同而不同)。這就要求數據在寫的時候需要有額外的對齊操作?？梢酝ㄟ^/sys/block/sda/queue/logical_block_size知道對齊的大小,一般都是512個字節。

無法進行IO合并。O_DIRECT繞過page cache/buffer cache直接寫存儲設備，這樣如果對同一塊數據進行重復寫就無法在內存中命中，page cache/buffer cache合并寫的功能就無法生效了。

降低順序讀寫效率。如果使用O_DIRECT打開文件，則讀/寫操作都會跳過cache，直接在存儲設備上讀/寫。因為沒有了cache，所以文件的順序讀寫使用O_DIRECT這種小IO請求的方式效率是比較低的。

總的來說，使用O_DIRECT來設置innodb_flush_method并不是100%對所有應用和場景都是適用的。

4.? 存儲控制器層

該層的緩沖都放在存儲控制器的對應板載cache中，它的目的主要是在存儲控制器層緩沖數據，避免慢速塊設備讀寫操作影響了IO的響應時間。

當數據被fsync()等刷到存儲層時，首先會發送到存儲控制器層。常見的存儲控制器就是Raid卡，而目前大部分的Raid卡都有1G或者更大的存儲容量。這個緩沖一般為易失性的存儲，通過板載電池/電容來保證該“易失性的存儲”的數據在機器斷電以后仍然會同步到底層的磁盤存儲介質上。

關于存儲控制器我們有一些幾個方面需要注意的：

write back/write through：

針對是否使用緩沖，一般的存儲控制器都提供write back和write through兩種方式。write back方式下，操作系統提交的寫數據請求直接寫入到緩沖中就返回成功；write through方式下，操作系統提交的寫數據請求必須要真正寫到底層磁盤介質上才返回成功。

電池/電容區別：

為了保證機器掉電以后在“易失性”緩沖中的數據能夠及時刷新到底層磁盤介質上，存儲控制器上都有電池/電容來保證。普通的電池有容量衰減的問題，也就是說每隔一段時間，板載的電池都要被控制充放電一次，以保證電池的容量。在電池充放過程中，被設置為write-back的存儲控制器會自動變為write 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

如果你每隔一段時間發現IO請求響應時間突然慢下來了，就有可能是這個問題哦。通過MegaCli -AdpEventLog -GetEvents -f mr_AdpEventLog.txt-aALL的日志中的Event Description: Battery started charging就可以確定是否發生了發生了充放電的情況。

由于電池有這個問題，新的Raid卡會配置電容來保證“易失性”緩沖中的數據能夠及時刷新到底層磁盤介質上，這樣就沒有充放電的問題了。

read/write ratio：

HP的smart array提供對cache的讀和寫的區別(Accelerator Ratio)，

hpacucli ctrl all show config detail|grep ‘Accelerator Ratio’

Accelerator Ratio: 25% Read / 75% Write

這樣你就可以根據應用的實際情況來設置用于緩存讀和緩沖寫的cache的比例了。

開啟Direct IO

為了能夠讓上層的設備使用Direct IO方式來繞過raid卡，對Raid需要設置開啟DirectIO方式：

/opt/MegaRAID/MegaCli/MegaCli64 -LDSetProp -Direct -Immediate -Lall -aAll

LSI flash raid：

上面我們提到了“易失性”緩沖，如果我們現在有一個非易失性的緩沖，并且容量達到幾百G，這樣的存儲控制器緩沖是不是更能給底層設備提速？作為老牌的Raid卡廠商，LSI目前就有這樣的存儲控制器，使用write back方式和比較依賴存儲控制器緩沖的應用可以考慮使用這種類型的存儲控制器。

write barriers

目前raid卡的cache是否有電池或者電容保護對Linux來說是不可見的，所以Linux為了保證日志文件系統的一致性，默認會打開write barriers，也就是說，它會不斷的刷新“易失性”緩沖，這樣會大大降低IO性能。所以如果你確信底層的電池能夠保證“易失性”緩沖會刷到底層磁盤設備的話，你可以在磁盤mount的時候加上-o nobarrier。

5.? 磁盤控制器層

該層的緩沖都放在磁盤控制器的對應板載cache中。存儲設備固件(firmware)會按規則排序將寫操作真正同步到介質中去。這里主要是保證寫的順序性，對機械磁盤來說，這樣可以盡量讓一次磁頭的移動能夠完成更多的磁碟寫入操作。

一般來說，DMA控制器也是放在磁盤這一層的，通過DMA控制器直接進行內存訪問，能夠節省CPU的資源。

對于機械硬盤，因為一般的磁盤設備上并沒有電池電容等，無法保證在機器掉電時磁盤cache里面的所有數據能夠及時同步到介質上，所以我們強烈建議把disk cache關閉掉。

Disk cache可以在存儲控制器層關閉。例如，使用MegaCli關閉的命令如下：

MegaCli -LDSetProp -DisDskCache?? -Lall -aALL

6.? 總結

從InnoDB到最終的介質，我們經過了各種緩沖，他們的目的其實很明確，就是為了解決：內存和磁盤的速度不匹配的問題，或者說是磁盤的速度過慢的問題。

另外，其實最懂數據是否應該緩沖/緩存的還是應用本身，VFS，存儲控制器和磁盤只能通過延遲寫入(以便合并重復IO，使隨機寫變成順序寫)來緩解底層存儲設備慢速造成的響應速度慢的問題。所以數據庫類型的應用都會來自己管理緩沖，然后盡量避免操作系統和底層設備的緩沖。

但是其實由于目前SSD固態硬盤和PCIe Flash卡的出現，內存和磁盤之間的速度差異被大大縮減了，這些緩沖是否必要，軟硬件哪些可改進的，對軟硬件工程師的一大挑戰。

參考：

標簽：

innodb_flush_method,O_DIRECT,O_SYNC,fsync,fdatasync,open,mysql5.6,page_cache,cache buffer,disk buffer,inode buffer,write through,write back,write barriers,dma

7.? 附錄

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)

總結

以上是生活随笔為你收集整理的mysql ssd inodb___细看InnoDB数据落盘 图解 MYSQL的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。