MySQL采用buffer機制，避免每次讀寫進行磁盤IO，提升效率：

• 《??緩沖池(buffer pool??)》
• 《??寫緩沖(change buffer)??》
• 《??日志緩沖(log buffer)??》

MySQL的buffer一頁的大小是16K，文件系統一頁的大小是4K，也就是說，MySQL將buffer中一頁數據刷入磁盤，要寫4個文件系統里的頁。

如上圖所示，MySQL里page=1的頁，物理上對應磁盤上的1+2+3+4四個格。

那么，問題來了，這個操作并非原子，如果執行到一半斷電，會不會出現問題呢？

會，這就是所謂的“頁數據損壞”。

如上圖所示，MySQL內page=1的頁準備刷入磁盤，才刷了3個文件系統里的頁，掉電了，則會出現：重啟后，page=1的頁，物理上對應磁盤上的1+2+3+4四個格，數據完整性被破壞。

畫外音：redo無法修復這類“頁數據損壞”的異常，修復的前提是“頁數據正確”并且redo日志正常。

如何解決這類“頁數據損壞”的問題呢？

很容易想到的方法是，能有一個“副本”，對原來的頁進行還原，這個存儲“副本”的地方，就是Double Write Buffer。

Double Write Buffer，但它與傳統的buffer又不同，它分為內存和磁盤的兩層架構。

畫外音：傳統的buffer，大部分是內存存儲;而DWB里的數據，是需要落地的。

如上圖所示，當有頁數據要刷盤時：

• 第一步：頁數據先memcopy到DWB的內存里；
• 第二步：DWB的內存里，會先刷到DWB的磁盤上；
• 第三步：DWB的內存里，再刷到數據磁盤存儲上；

畫外音：DWB由128個頁構成，容量只有2M。

步驟2和步驟3要寫2次磁盤，這就是“Double Write”的由來。

DWB為什么能解決“頁數據損壞”問題呢？

假設步驟2掉電，磁盤里依然是1+2+3+4的完整數據。

畫外音：只要有頁數據完整，就能通過redo還原數據。

假如步驟3掉電，DWB里存儲著完整的數據。

所以，一定不會出現“頁數據損壞”問題。

畫外音：寫了2次，總有一個地方的數據是OK的。

自己實驗了幾十次，仍沒能復現“頁數據損壞”，在網上找了一個“頁數據損壞”時，MySQL重啟過程利用DWB修復頁數據的圖。

可以看到，啟動過程中：

• InnoDB檢測到上一次為異常關閉；
• 嘗試恢復ibd數據，失敗；
• 從DWB中恢復寫了一半的頁；

能夠通過DWB保證頁數據的完整性，但畢竟DWB要寫兩次磁盤，會不會導致數據庫性能急劇降低呢？

分析DWB執行的三個步驟：

• 第一步，頁數據memcopy到DWB的內存，速度很快；
• 第二步，DWB的內存fsync刷到DWB的磁盤，屬于順序追加寫，速度也很快；
• 第三步，刷磁盤，隨機寫，本來就需要進行，不屬于額外操作；

另外，128頁(每頁16K)2M的DWB，會分兩次刷入磁盤，每次最多64頁，即1M的數據，執行也是非常之快的。

綜上，性能會有所影響，但影響并不大。

畫外音：

• write--ahead-log之所以性能高，就是因為順序追加寫；
• 有第三方測評，評估約10%性能損失；

更具體的，InnoDB里有兩個變量可以查看double write buffer相關的情況：

• Innodb_dblwr_pages_written：記錄寫入DWB中頁的數量。
• Innodb_dblwr_writes：記錄DWB寫操作的次數。

可以通過：

show global status like "%dblwr%"

來進行查詢。

結尾

MySQL有很強的數據安全性機制：

• 在異常崩潰時，如果不出現“頁數據損壞”，能夠通過redo恢復數據；
• 在出現“頁數據損壞”時，能夠通過double write buffer恢復頁數據；

double write buffer：

• 不是一個內存buffer，是一個內存/磁盤兩層的結構，是InnoDB里On-Disk架構里很重要的一部分；
• 是一個通過寫兩次，保證頁完整性的機制；

知其然，知其所以然。

思路比結論重要，希望大家有收獲。