本篇文章為大家展示了我很理解MySQL中的double write，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

為桓仁等地區(qū)用戶提供了全套網(wǎng)頁設計制作服務，及桓仁網(wǎng)站建設行業(yè)解決方案。主營業(yè)務為成都網(wǎng)站制作、網(wǎng)站設計、外貿(mào)網(wǎng)站建設、桓仁網(wǎng)站設計，以傳統(tǒng)方式定制建設網(wǎng)站，并提供域名空間備案等一條龍服務，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！

    MySQL里的double write是InnoDB的三大閃亮特性，另外兩個是insert buffer 和自適應哈希，其實還有幾個比如異步IO，F(xiàn)lush neighbour Page(刷新鄰接頁），這個和系統(tǒng)層面的關(guān)聯(lián)性較高，所以三大亮點還是更有針對性的。

   當然一說到MySQL里的double write,其實主要是要應對一個很自然的問題，那就是partial write。

經(jīng)典的partial write問題

   這個問題比較經(jīng)典，很多數(shù)據(jù)庫設計中都需要考慮到這樣一個臨界點的問題，MySQL中的頁是16k,數(shù)據(jù)的校驗是按照這個為單位進行的，而操作系統(tǒng)層面的數(shù)據(jù)單位肯定達不到16k,比如是4k,那么一旦發(fā)生斷電的時候，只保留了部分寫入，如果是Oracle DBA一般對此都會很淡定，說用redo來恢復嘛，但是可能我們被屏蔽了一些細節(jié)，MySQL在恢復的過程中一個基準是檢查page的checksum，也就是page的最后事務號，發(fā)生這種partial page write 的問題時，因為page已經(jīng)損壞，所以就無法定位到page中的事務號，所以這個時候redo就無法直接恢復。

   由此引申一點，partial write的問題在Oracle中肯定也會存在，但是只是Oracle替我們把這個過程平滑的做好了。其中有設計的差異，還有恢復技術(shù)的差別。但是無論如何這個問題都不會繞過去，還得解決。

   所以這一類問題，如果討論起來，那可以討論很長時間，可以把體系結(jié)構(gòu)里的方方面面拿出來分析，做對比。

簡單分析double write問題

   對此我畫了一個相對簡陋的圖，也歡迎大家提出改進建議。

    總體來說，double write buffer就是一種緩沖緩存技術(shù)，主要的設計就是為了防止數(shù)據(jù)在斷電，異常情況下丟失數(shù)據(jù)。里面有幾個點需要注意的就是，數(shù)據(jù)在buffer pool中修改后成了臟頁，這個過程會產(chǎn)生binglog記錄和redo記錄，當然數(shù)據(jù)寫入數(shù)據(jù)文件是一個異步的工作，如果細看，在共享表空間（system tablespace）中會存在一個2M的空間，分為2個單元，一共128個頁，其中120個用于批量刷臟數(shù)據(jù)，另外8個用于Single Page Flush。根據(jù)阿里同學的分析主要是做區(qū)分是因為批量刷臟是后臺線程做的，這樣不影響前臺線程。而Single page flush是用戶線程發(fā)起的，需要盡快的刷臟并替換出一個空閑頁出來。所以不是一個嚴格的64+64的拆分。

       而數(shù)據(jù)刷新的過程，是先使用memcopy把臟數(shù)據(jù)復制到內(nèi)存中的double write buffer,分兩次寫完，每次寫1MB到共享表空間，然后就是調(diào)用fsync來同步到磁盤。這里有一點需要注意的是，這個刷新到共享表空間的過程，雖然是兩次，但是是順序?qū)?，所以開銷不會很大，也就不會像大家想象的double write性能可能很差，根據(jù)Percona的測試，大概也就是5%左右的差別，數(shù)據(jù)重要還是性能更重要，這是一個基本的命題。當然后續(xù)會再寫入對應的表空間文件中，這個過程就是隨機寫，性能開銷就會大一些。所以在早些時候是用SSD的時候很多人也會帶有如此的顧慮，順序?qū)戇€是隨機寫。

    當然double write這么設計就是全面為了作為恢復而用，要不這么大張旗鼓就不值得了。這個圖來源于 http://blog.csdn.net/renfengjun/article/details/41541809

  我覺得已經(jīng)說得很明白了，就直接引用過來了。

   可以看到里面的一個中心詞就是checksum,如果出現(xiàn)了partil write的時候，比如斷電，那么兩次寫的過程中，很可能page是不一致的，這樣checksum校驗就很可能出現(xiàn)問題，而出現(xiàn)問題的時候，因為有了前期寫入共享表空間的頁信息，所以就可以重構(gòu)出頁的信息重新寫入。

double write的另外一個作用

    double write其實還有一個特點，就是將數(shù)據(jù)從double write buffer寫到真正的segment中的時候, 系統(tǒng)會自動合并連接空間刷新的方式, 這樣一來每次就可以刷新多個pages，提高效率。

比如下面的環(huán)境，我們可以根據(jù)show status的結(jié)果來得到一個基本的合并頁的情況。

> show status like '%dbl%';  

| Variable_name              | Value    |

| Innodb_dblwr_pages_written | 23196544 |
| Innodb_dblwr_writes        | 4639373  |
通過InnoDB_dblwr_pages_written/InnoDB_dblwr_writes  就可以得到，通過指標也可基本看明白。
   

Percona中的double write改進

   當然對于double write，在Percona中也在持續(xù)改進，在Percona 5.7版本中做了一個改進，你可以看到一個新的參數(shù)，innodb_parallel_doublewrite_path

| innodb_parallel_doublewrite_path | xb_doublewrite |在系統(tǒng)層面，也會存在一個30的一個文件對應。

-rw-r----- 1 mysql mysql 31457280 Mar 28 17:54 xb_doublewrite也就是并行double write,關(guān)于這個特性的詳細描述和測試，可以參考。https://www.percona.com/blog/2016/05/09/percona-server-5-7-parallel-doublewrite/?utm_source=tuicool&utm_medium=referral

里面提供了很多詳細測試的對比和分析。當然MariaDB,Facebook,Aurora也有一些自己的實現(xiàn)方式和考慮，這個限于精力，還沒有細細測試分析。

上述內(nèi)容就是我很理解MySQL中的double write，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設公司行業(yè)資訊頻道。

本文標題：我很理解MySQL中的doublewrite-創(chuàng)新互聯(lián)
標題鏈接：http://aaarwkj.com/article46/cojgeg.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)網(wǎng)站建設、營銷型網(wǎng)站建設、網(wǎng)站設計公司、外貿(mào)建站、服務器托管、App設計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)