MySQL 基礎知識梳理學習（五）----詳解MySQL兩次寫的設計及實現

 一 . 兩次寫提出的背景或要解決的問題

兩次寫（InnoDB Double Write）是Innodb中很獨特的一個功能點。因為Innodb中的日誌是邏輯的，所謂邏輯就是比如插入一條記錄時，它可能會在某一個頁面（這條記錄最終被插入的位置）的多個偏移位置寫入某個長度的值，例如頁頭的記錄數、槽數、頁尾槽數據、頁中的記錄值等。這些本是一些物理操作，而Innodb為了節省日誌量及其它原因，設計為邏輯處理的方式，即在一個頁面上插入一條記錄時，對應的日誌內容包括表空間號、頁面號、將被記錄的各個列的值等內容，在真正物理插入的時候，才會將日誌邏輯操作轉換為前面的物理操作。

先有邏輯日誌，再有物理操作，但是這樣需要有一個前提，就是物理操作的頁面是正確的。如果那個數據頁面本身是錯誤的，這種錯誤可能是上次的操作導致的寫斷裂（1個頁面為16KB，分多次寫入，後面的可能沒有寫成功，導致這個頁面不完整）或者其它原因，那麼這個邏輯操作就沒辦法完成了。因為如果這個頁面不正確的話，裡面的數據是無效的，就可能會產生各種不可預料的問題。

因此首先要保證這個頁面是正確的，方法就是兩次寫。

二 . 單一頁面刷盤

兩次寫包括兩種方法，一種是對單獨一個頁面刷盤時的兩次寫，另一種是批量刷盤時的兩次寫。單一頁面刷盤實際上是MySQL5.5版本的實現方式。

2.1  結構設計及原理

MySQL在系統頁面上記錄關於兩次寫的信息如要如下：

2.2 刷盤的過程

每次刷盤前，都會將要刷盤的頁面信息臨時保存到記憶體的數組中，這個空間大小也是128個頁面，這個緩存稱為兩次寫緩存數組。有了這些信息，單個頁面刷盤的兩次寫就可以正常運轉了。

step 1 先在兩次寫緩存數組中，找到一個空閑位置，並將這個位置標記為已使用，然後，再把要刷新的頁面數據複製到標記的緩存空間中。

step 2 將頁面的數據刷到兩次寫文件中，即ibdata文件中。此時頁面是持久化。

複製的數據量是一個頁面的大小，偏移位置是這個頁面在兩次寫緩存空間中的位置，對應著TRX_SYS_DOUBLEWRITE_BLOCK1或TRX_SYS_DOUBLEWRITE_BLOCK2的位置。因為記憶體中的兩次寫緩存數組是128個元素，而對應的TRX_SYS_DOUBLEWRITE_BLOCK1及TRX_SYS_DOUBLEWRITE_BLOCK2也是128個頁面，它們是一一對應的，所以具體刷到什麼位置，可以計算出來。

step 3 頁面刷盤，即數據刷到真實的位置，也許刷到的是ibdata文件，也許是某一個表的ibd文件中的某一個位置。

需要註意的是，因為Buffer Pool中的頁面，刷到真實文件時是非同步IO的，那麼只有當刷到自己表空間的刷盤操作完成後，兩次寫緩存數組的數據才可以被覆蓋，或者說，這個頁面對應的兩次寫文件中的頁面才可以被覆蓋，不然又可能造成這個兩次寫位置的頁面被新的頁面覆蓋的問題。如果此時上次的真實表空間的刷盤沒有完成，同時產生了頁面斷裂的問題，這樣就出現了該頁面不可恢復的問題，兩次寫的意義也就沒有了。

三 . 批量頁面刷盤

很明顯，單一刷盤情況下開啟了兩次寫，IO次數的增加會導致性能差很多，在新版本MySQL 5.7中，新增加入了針對Buffer Pool  批量刷盤的兩次寫實現方式。

3.1 實現原理 

MySQL 5.7的實現方式新增了一個文件，文件路徑及名稱可以通過參數innodb_parallel_doublewrite_path來控制。啟動資料庫時，如果兩次寫文件不存在，那麼這個參數可以指定絕對路徑的兩次寫文件，也可以只指定文件名使文件被預設創建到datadir目錄下。

批量刷盤包括兩種方式，分別是LRU方式和LIST方式。當Buffer Pool空間不足時，再載入新的頁面就必須要將一些不怎麼用到的、舊的頁面淘汰出去，此時系統就會從LRU鏈表中找到最老的頁面，進行批量刷盤，將釋放的空間加入到空閑空間中去，這種情況就是LRU刷盤。當日誌空間不足，或者是後臺MASTER線程在定時刷盤時，不需要區分頁面的新舊狀態，只需要選擇LSN最小的那些頁面，從前到後刷一批頁面到文件中，此時所用的策略就是LIST方式。

在批量刷盤的兩次寫中，這兩種刷盤方法對應的兩次寫空間互不幹涉。

InnoDB自身的整個Buffer Pool分為多個Instance，每個Instance管理自身的一套兩次寫空間，而針對每一個Instance的每一個刷盤方法的批量緩存空間大小，是通過參數innodb_doublewrite_batch_size來控制的，預設值為120。這樣算下來，innodb_parallel_doublewrite_path所指的文件大小的計算方法如下：

兩次寫文件頁面個數=innodb_buffer_pool_instances*2(LIST+LRU)*innodb_doublewrite_batch_size.

從圖中可以看出落到最終的每一個shard,其實就是一個batch，對應的參數就是innodb_doublewrite_batch_size。一個shard，有一個數組，長度為innodb_doublewrite_batch_size，與單一頁面刷盤的兩次寫是一樣的，只是這個數組只屬於一個shard而已。

3.2 批量刷盤的過程 

 假設由於頁面淘汰，系統要做一次批量刷盤，這次就是LRU方式的，那麼此時系統就需要將當前頁面加入到兩次寫緩存中，首先根據當前頁面所在的Instance號及刷盤類型就可以找到對應的shard緩存，找到緩存後，判斷當前shard是否已經滿了，即是否已經達到innodb_doublewrite_batch_size的大小，如果沒有達到，則將當前頁面內容追加複製到當前的shard緩存中，這樣當前頁面的刷盤操作就完成了。這裡並不像單一頁面那樣，先寫入緩存空間中，然後寫入ibdata文件的兩次寫空間，最後還需要立即將頁面的真實內容刷入表空間，對於批量刷盤來說，只需要寫入到shard緩存即可。

如果當前shard中緩存的頁面個數已經達到了innodb_doublewrite_batch_size，則說明當前緩存空間已經滿了，此時不得不將當前shard緩存的頁面寫入兩次寫文件中，寫完之後再將兩次寫文件FLUSH到磁碟，最後將對應的真實頁面刷盤，此時可能是隨機寫入了，因為對應的兩次寫緩存中雖然是連續的，但對應的真實頁面就不會這樣了。這裡需要註意的一點就是，表空間頁面的刷盤，是非同步IO操作，此時需要等待非同步IO完成，且整個shard中的頁面都刷盤後，刷盤操作才可以繼續向後執行，而這個shard也可以再次重新使用了，緩存中的數據也都會被清空。

需要註意的是，上面過程中寫入是連續innodb_doublewrite_batch_size 個頁面，所以性能會比寫入多次而每次致謝一個頁面的情況好很多。批量刷盤的情況下，有可能每隔innodb_doublewrite_batch_size個頁面的刷盤操作，就會出現一次等待操作，且等待時間長短不一定，但這也是在單一頁面刷盤的基礎上優化過的，做了改進。

四 . 兩次寫的作用

在資料庫啟動時（異常關閉的情況下），都會做資料庫恢復（redo）操作。在恢復的過程中，資料庫會檢查頁面是否合法（校驗），如果發現一個頁面的校驗結果不一致，則此時就會用到兩次寫機制，用兩次寫空間中的數據來恢復異常頁面的數據，這也正是為處理這樣的錯誤而設計的。此時的處理機制就是，將兩次寫的兩個簇都讀出來，再將innodb_parallel_doublewrite_path文件的內容讀出來，然後將所有這些頁面寫回到對應的頁面中去，這樣就可以保證這些頁面是正確的，並且是在寫入前已經更新過的（最新數據）。在寫回對應頁面中去之後，就可以在此基礎上繼續做資料庫恢復了，且不會遇到這樣的問題了，因為最後有可能產生寫斷裂的數據頁面都恢復了。

上面所講的都是數據頁面有問題的情況下可以通過兩次寫頁面來恢復，但是如果兩次寫頁面本身發生寫斷裂怎麼辦呢？ 對於這個問題，大家不必擔心。因為如果兩次寫有問題，則數據頁面本身就不會做寫操作（一定是先邏輯後物理嘛，邏輯掛了，就沒有後面的物理了。），此時系統掛了，發生錯誤的是兩次寫頁面，而數據頁面在掛之前都是在Buffer裡面，文件中依然是當前事務操作前的值，並沒有變化，還是一致狀態，這意味著兩次寫頁面根本就不會用到。

-----主要內容參考梳理於網路知識，此短文僅為學習筆記，在此原創作者感謝！