MySQL中Double Write Buffer的分析是怎樣的

這篇文章將為大家詳細講解有關MySQL中Double Write Buffer的分析是怎樣的，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

Double Write Buffer是什么？
這是一個buffer，存在于內存中，在持久化到磁盤的時候，這一部分數據會寫進innodb的表空間里，由一段連續的pages組成；
Double Write這個特性，和命名所描述的完全一致：寫兩遍~

為什么要引入Double Write Buffer？
引入Double Write Buffer是為了解決partial page write的問題，關于這個問題的描述，引用楊大師的原文，
>>>
InnoDB 的Page Size一般是16KB，其數據校驗也是針對這16KB來計算的，將數據寫入到磁盤是以Page為單位進行操作的。
而計算機硬件和操作系統，在極端情況下（比如斷電）往往并不能保證這一操作的原子性，
16K的數據，寫入4K 時，發生了系統斷電/os crash ，只有一部分寫是成功的，這種情況下就是 partial page write 問題。
<<<

追問1：拋開page不完全寫入的這個概念，DB在做crash recovery的時候，不是可以從redo log來重新做一遍么，為什么還要這個特性呢？
解答：原因有兩個，
1.由于Page的不完全寫入，實際上這個出問題的Page由于沒有完全寫入，所以這個page的checksum是無效的，想恢復這個page的時候，無法定位是哪個page寫出了問題；
2.redo-log的原因， MySQL的innodb在生成redo-log的時候，并沒有寫入具體數據的變更，而是只記錄了這個變更所在的page信息，具體的格式如下
    [Space-id] [Page-id] [Where-in-the-page-to-modify] [Payload]
其中，space-id記錄的是這個信息存儲于哪個redo-log文件，page-id記錄的就是page的id（..._(:з」∠)_...），其余信息基本如描述所示；
由于redo-log的這種記錄方式，使得MySQL不能依靠redo-log去把崩潰前后一段時間的整個事務全部找出來，然后重做；（存都沒存數據，怎么恢復嘛╮(╯▽╰)╭）；

Double Write Buffer工作在哪個階段/時機？
當innodb從buffer pool中刷新pages到磁盤時，并不是直接往磁盤寫，而是先寫進這個Double Write Buffer，
然后馬上調用fsync()，將這一部分數據寫到磁盤上，之后再把這部分的pages寫到真正的數據文件里面去；

Double Write Buffer能不能解決問題？
答案肯定是可以~
情景1：innodb從buffer pool往Double Write Buffer寫pages的時候，出事故了，發生了page的部分寫入；
分析：innodb在crash recovery的時候，檢查到數據文件的pages都是正常的，通過比較LSN/checksum能夠檢查到數據文件的具體狀態，然后再去恢復數據；
情景2：從Double Write Buffer往真正的數據文件寫pages的時候，出事故了，發生了page的部分寫入；
分析：由于Double Write Buffer本身有這個pages的完整內容，從Double Write Buffer重新往數據文件寫pages即可；

Double Write Buffer對性能的影響？
由于Double Write Buffer本身是一段完全連續的空間，所以Double Write Buffer從內存寫到磁盤的時候是完完全全的順序寫，
所以對性能的影響并沒有從1個fsync()到2個fsync()這么夸張，引用percona的工程師的判斷：性能影響不超過5%-10%；

關于MySQL中Double Write Buffer的分析是怎樣的就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。