1.? 概述

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

我們通過(guò)下圖看一下相關(guān)的緩沖：

圖 1 innodb all buffers

從上圖中，我們可以看到，數(shù)據(jù)InnoDB到磁盤需要經(jīng)過(guò)

InnoDB buffer pool， Redo log buffer。這個(gè)是InnoDB應(yīng)用系統(tǒng)本身的緩沖。

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

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

Write-Back buffer。(可設(shè)置存儲(chǔ)控制器參數(shù)繞過(guò))

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

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

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

下面我們對(duì)這些緩沖自頂向下逐一進(jìn)行詳細(xì)的介紹。

2.? InnoDB層

該層的緩沖都放在主機(jī)內(nèi)存中，它的目的主要是在應(yīng)用層管理自己的數(shù)據(jù)，避免慢速的讀寫操作影響了InnoDB的響應(yīng)時(shí)間。

InnoDB層主要包括兩個(gè)buffer：redo log buffer和innodb buffer pool。redo log buffer用來(lái)暫存對(duì)重做日志redo log的日志寫，InnoDB buffer pool存儲(chǔ)了從磁盤設(shè)備讀到的InnoDB數(shù)據(jù)，也緩沖了對(duì)InnoDB數(shù)據(jù)寫，即臟頁(yè)數(shù)據(jù)。如果主機(jī)掉電或者M(jìn)ySQL異常宕機(jī)，innodb buffer pool將無(wú)法及時(shí)刷新到磁盤，那么InnoDB就只能從上一個(gè)checkpoint使用redo log來(lái)前滾；而redo log buffer如果不能及時(shí)刷新到磁盤，那么由于redo log中數(shù)據(jù)的丟失，就算使用redo 前滾，用戶提交的事務(wù)由于沒(méi)有真正的記錄到非易失型的磁盤介質(zhì)中，就丟失掉了。

控制redo log buffer刷新時(shí)機(jī)的參數(shù)是innodb_flush_log_at_trx_commit，而控制redo log buffer和innodb buffer pool刷新方式的參數(shù)為innodb_flush_method。針對(duì)這兩個(gè)參數(shù)詳細(xì)介紹的文章有非常多，我們這里主要從緩沖的角度來(lái)解析。

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示意圖

這里偷個(gè)懶，直接引用應(yīng)元的圖。另外，更新一下innodb_flush_log_at_trx_commit=2時(shí)在5.6的變化：

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

= 5.6.6：每隔innodb_flush_log_at_timeout秒將數(shù)據(jù)刷新到磁盤中去。

我們這里不再詳細(xì)討論這個(gè)問(wèn)題，具體細(xì)節(jié)可以參考MySQL數(shù)據(jù)丟失討論

2.2. innodb_flush_method

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

fdatasync

O_DSYNC

O_DIRECT

O_DIRECT_NO_FSYNC

這里我們注意到有幾個(gè)問(wèn)題：

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

這些參數(shù)里面沒(méi)有在windows環(huán)境下的參數(shù)配置，現(xiàn)在大家都開始不鳥蓋茨兄了？其實(shí)在注釋里面寫了，windows就使用async_unbuffered，并且不允許修改，所以沒(méi)有寫到列表里面。

前三個(gè)參數(shù)值只允許在6.6和5.6.6之前的版本中用，從5.6.7開始新增了O_DIRECT_NO_FSYNC。也就是說(shuō)用O_DIRECT打開文件，但是不用fsync()同步數(shù)據(jù)。這個(gè)由于在較新的Linux內(nèi)核和部分文件系統(tǒng)中，使用O_DIRECT就可以保證數(shù)據(jù)安全，不用專門再用fsync()來(lái)同步，保證元數(shù)據(jù)也刷新到非易失型的磁盤介質(zhì)。例如：XFS就不能用這個(gè)參數(shù)。O_DIRECT繞過(guò)了page cache，為什么還要用fsync()再刷新以下，我們?cè)谙鹿?jié)專門討論。

有人會(huì)說(shuō)referense文檔有個(gè)小bug，6.6之前的版本default是fdatasync，但是Valid Values可指定的值內(nèi)竟然沒(méi)有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可選值

其實(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ù)值來(lái)指明“數(shù)據(jù)文件”和“日志文件”是用fsync()打開的(注意：不是fdatasync())，這個(gè)是歷史原因，所以5.6特意把它從可選值中去掉，避免誤解。當(dāng)然你如果仍然要使用fsync()來(lái)同步，那就對(duì)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è)備時(shí)，可以在mount 時(shí)使用forcedirectio使得整個(gè)文件系統(tǒng)都是以directio打開。這里指明為innodb而不是MySQL的原因是，MyISAM不要用directio())

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

#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 */

也就是說(shuō)，對(duì)于日志文件來(lái)說(shuō)，如果設(shè)置innodb_flush_log_at_trx_commit為2，O_DIRECT是無(wú)效的。

閑話少說(shuō)，下面的一個(gè)表和一張圖能夠更加直觀的說(shuō)明問(wèn)題：

重新加工了orczhou的刷新關(guān)系表：

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數(shù)據(jù)文件和日志刷新對(duì)應(yīng)表

圖 3 innodb_flush_method數(shù)據(jù)文件和日志刷新示意圖

3.? VFS層

該層的緩沖都放在主機(jī)內(nèi)存中，它的目的主要是在操作系統(tǒng)層緩沖數(shù)據(jù)，避免慢速塊設(shè)備讀寫操作影響了IO的響應(yīng)時(shí)間。

3.1. 細(xì)究O_DIRECT/O_SYNC標(biāo)簽

在前面redo log buffer和innodb buffer pool的討論中涉及到很多數(shù)據(jù)刷新和數(shù)據(jù)安全的問(wèn)題，我們?cè)诒竟?jié)中，專門討論O_DIRECT/O_SYNC標(biāo)簽的含義。

我們打開一個(gè)文件并寫入數(shù)據(jù)，VFS和文件系統(tǒng)是怎么把數(shù)據(jù)寫到硬件層列，下圖展示了關(guān)鍵的數(shù)據(jù)結(jié)構(gòu)：

圖 4 VFS cache圖

圖中，我們看到該層中主要有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)的不同，一般來(lái)說(shuō)對(duì)一個(gè)文件的寫入操作包括兩部分，對(duì)數(shù)據(jù)本身的寫入操作，以及對(duì)文件屬性(metadata元數(shù)據(jù))的寫入操作(這里的文件屬性包括目錄，inode等)。

了解了這些以后，我們就能夠比較簡(jiǎn)單的說(shuō)清楚各個(gè)標(biāo)志的意義了：

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()的區(qū)別在于：是在每一個(gè)IO提交的時(shí)刻都針對(duì)對(duì)應(yīng)的page cache和buffer cache進(jìn)行刷新；還是在一定數(shù)據(jù)的寫操作以后調(diào)用fdatasync()的時(shí)刻對(duì)整個(gè)page cache和buffer cache進(jìn)行刷新。O_SYNC和fsync()的區(qū)別同理。

page cache和buffer cache的主要區(qū)別在于一個(gè)是面向?qū)嶋H文件數(shù)據(jù)，一個(gè)是面向塊設(shè)備。在VFS上層使用open()方式打開那些使用mkfs做成文件系統(tǒng)的文件，你就會(huì)用到page cache和buffer cache，而如果你在Linux操作系統(tǒng)上使用dd這種方式來(lái)操作Linux的塊設(shè)備，你就只會(huì)用到buffer cache。

O_DSYNC和O_SYNC的區(qū)別在于：O_DSYNC告訴內(nèi)核，當(dāng)向文件寫入數(shù)據(jù)的時(shí)候，只有當(dāng)數(shù)據(jù)寫到了磁盤時(shí)，寫入操作才算完成(write才返回成功)。O_SYNC比O_DSYNC更嚴(yán)格，不僅要求數(shù)據(jù)已經(jīng)寫到了磁盤，而且對(duì)應(yīng)的數(shù)據(jù)文件的屬性(例如文件inode，相關(guān)的目錄變化等)也需要更新完成才算write操作成功。可見O_SYNC較之O_DSYNC要多做一些操作。

Open()的referense中還有一個(gè)O_ASYNC，它主要用于terminals, pseudoterminals, sockets, 和pipes/FIFOs，是信號(hào)驅(qū)動(dòng)的IO，當(dāng)設(shè)備可讀寫時(shí)發(fā)送一個(gè)信號(hào)(SIGIO)，應(yīng)用進(jìn)程捕獲這個(gè)信號(hào)來(lái)進(jìn)行IO操作。

O_SYNC和O_DIRECT都是同步寫，也就是說(shuō)只有寫成功了才會(huì)返回。

回過(guò)頭來(lái)，我們?cè)賮?lái)看innodb_flush_log_at_trx_commit的配置就比較好理解了。O_DIRECT直接IO繞過(guò)了page cache/buffer cache以后為什么還需要fsync()了，就是為了把directory cache和inode cache元數(shù)據(jù)也刷新到存儲(chǔ)設(shè)備上。

而由于內(nèi)核和文件系統(tǒng)的更新，有些文件系統(tǒng)能夠保證保證在O_DIRECT方式下不用fsync()同步元數(shù)據(jù)也不會(huì)導(dǎo)致數(shù)據(jù)安全性問(wèn)題，所以InnoDB又提供了O_DIRECT_NO_FSYNC的方式。

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

3.2. O_DIRECT優(yōu)劣勢(shì)

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

3.2.1.?? 優(yōu)勢(shì)：

節(jié)省操作系統(tǒng)內(nèi)存：O_DIRECT直接繞過(guò)page cache/buffer cache，這樣避免InnoDB在讀寫數(shù)據(jù)少占用操作系統(tǒng)的內(nèi)存，把更多的內(nèi)存留個(gè)innodb buffer pool來(lái)使用。

節(jié)省CPU。另外，內(nèi)存到存儲(chǔ)設(shè)備的傳輸方式主要有poll，中斷和DMA方式。使用O_DIRECT方式提示操作系統(tǒng)盡量使用DMA方式來(lái)進(jìn)行存儲(chǔ)設(shè)備操作，節(jié)省CPU。

3.2.2.?? 劣勢(shì)

字節(jié)對(duì)齊。O_DIRECT方式要求寫數(shù)據(jù)時(shí)，內(nèi)存是字節(jié)對(duì)齊的(對(duì)齊的方式根據(jù)內(nèi)核和文件系統(tǒng)的不同而不同)。這就要求數(shù)據(jù)在寫的時(shí)候需要有額外的對(duì)齊操作。可以通過(guò)/sys/block/sda/queue/logical_block_size知道對(duì)齊的大小,一般都是512個(gè)字節(jié)。

無(wú)法進(jìn)行IO合并。O_DIRECT繞過(guò)page cache/buffer cache直接寫存儲(chǔ)設(shè)備，這樣如果對(duì)同一塊數(shù)據(jù)進(jìn)行重復(fù)寫就無(wú)法在內(nèi)存中命中，page cache/buffer cache合并寫的功能就無(wú)法生效了。

降低順序讀寫效率。如果使用O_DIRECT打開文件，則讀/寫操作都會(huì)跳過(guò)cache，直接在存儲(chǔ)設(shè)備上讀/寫。因?yàn)闆](méi)有了cache，所以文件的順序讀寫使用O_DIRECT這種小IO請(qǐng)求的方式效率是比較低的。

總的來(lái)說(shuō)，使用O_DIRECT來(lái)設(shè)置innodb_flush_method并不是100%對(duì)所有應(yīng)用和場(chǎng)景都是適用的。

4.? 存儲(chǔ)控制器層

該層的緩沖都放在存儲(chǔ)控制器的對(duì)應(yīng)板載cache中，它的目的主要是在存儲(chǔ)控制器層緩沖數(shù)據(jù)，避免慢速塊設(shè)備讀寫操作影響了IO的響應(yīng)時(shí)間。

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

關(guān)于存儲(chǔ)控制器我們有一些幾個(gè)方面需要注意的：

write back/write through：

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

電池/電容區(qū)別：

為了保證機(jī)器掉電以后在“易失性”緩沖中的數(shù)據(jù)能夠及時(shí)刷新到底層磁盤介質(zhì)上，存儲(chǔ)控制器上都有電池/電容來(lái)保證。普通的電池有容量衰減的問(wèn)題，也就是說(shuō)每隔一段時(shí)間，板載的電池都要被控制充放電一次，以保證電池的容量。在電池充放過(guò)程中，被設(shè)置為write-back的存儲(chǔ)控制器會(huì)自動(dòng)變?yōu)閣rite through。這個(gè)充放電的周期(Learn Cycle周期)一般為90天，LSI卡可以通過(guò)MegaCli來(lái)查看：

#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

如果你每隔一段時(shí)間發(fā)現(xiàn)IO請(qǐng)求響應(yīng)時(shí)間突然慢下來(lái)了，就有可能是這個(gè)問(wèn)題哦。通過(guò)MegaCli -AdpEventLog -GetEvents -f mr_AdpEventLog.txt-aALL的日志中的Event Description: Battery started charging就可以確定是否發(fā)生了發(fā)生了充放電的情況。

由于電池有這個(gè)問(wèn)題，新的Raid卡會(huì)配置電容來(lái)保證“易失性”緩沖中的數(shù)據(jù)能夠及時(shí)刷新到底層磁盤介質(zhì)上，這樣就沒(méi)有充放電的問(wèn)題了。

read/write ratio：

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

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

Accelerator Ratio: 25% Read / 75% Write

這樣你就可以根據(jù)應(yīng)用的實(shí)際情況來(lái)設(shè)置用于緩存讀和緩沖寫的cache的比例了。

開啟Direct IO

為了能夠讓上層的設(shè)備使用Direct IO方式來(lái)繞過(guò)raid卡，對(duì)Raid需要設(shè)置開啟DirectIO方式：

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

LSI flash raid：

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

write barriers

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

5.? 磁盤控制器層

該層的緩沖都放在磁盤控制器的對(duì)應(yīng)板載cache中。存儲(chǔ)設(shè)備固件(firmware)會(huì)按規(guī)則排序?qū)懖僮髡嬲降浇橘|(zhì)中去。這里主要是保證寫的順序性，對(duì)機(jī)械磁盤來(lái)說(shuō)，這樣可以盡量讓一次磁頭的移動(dòng)能夠完成更多的磁碟寫入操作。

一般來(lái)說(shuō)，DMA控制器也是放在磁盤這一層的，通過(guò)DMA控制器直接進(jìn)行內(nèi)存訪問(wèn)，能夠節(jié)省CPU的資源。

對(duì)于機(jī)械硬盤，因?yàn)橐话愕拇疟P設(shè)備上并沒(méi)有電池電容等，無(wú)法保證在機(jī)器掉電時(shí)磁盤cache里面的所有數(shù)據(jù)能夠及時(shí)同步到介質(zhì)上，所以我們強(qiáng)烈建議把disk cache關(guān)閉掉。

Disk cache可以在存儲(chǔ)控制器層關(guān)閉。例如，使用MegaCli關(guān)閉的命令如下：

MegaCli -LDSetProp -DisDskCache?? -Lall -aALL

6.? 總結(jié)

從InnoDB到最終的介質(zhì)，我們經(jīng)過(guò)了各種緩沖，他們的目的其實(shí)很明確，就是為了解決：內(nèi)存和磁盤的速度不匹配的問(wèn)題，或者說(shuō)是磁盤的速度過(guò)慢的問(wèn)題。

另外，其實(shí)最懂?dāng)?shù)據(jù)是否應(yīng)該緩沖/緩存的還是應(yīng)用本身，VFS，存儲(chǔ)控制器和磁盤只能通過(guò)延遲寫入(以便合并重復(fù)IO，使隨機(jī)寫變成順序?qū)?來(lái)緩解底層存儲(chǔ)設(shè)備慢速造成的響應(yīng)速度慢的問(wèn)題。所以數(shù)據(jù)庫(kù)類型的應(yīng)用都會(huì)來(lái)自己管理緩沖，然后盡量避免操作系統(tǒng)和底層設(shè)備的緩沖。

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

參考：

標(biāo)簽：

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

錯(cuò)誤的方式:

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)

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。