MySQL之Double Write Buffer分析

之前有閱讀過相關的文檔和資料，總歸差了點意思，這次抽出時間仔細推敲了一下，把一些結果記錄下來；

楊大師的博文給了很大的幫助：http://blog.itpub.net/22664653/viewspace-1140915/

-------------------------------------------------------------------------------------正文------------------------------------------------------------------------------------

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%；

-------------------------------------------------------------------------------------結尾------------------------------------------------------------------------------------

PS：MySQL的crash recovery不僅依靠了redo log，應該還有binlog的功勞在裡面，不過這方面了解的不是很清晰，挖個坑，以後推敲......坑坑坑

PPS：新年新氣象~部落格施工繼續~