MySQL8.0 redo日誌系統優化

2019 年 11 月 10 日
筆記

背景

現在主流的數據庫系統的故障恢復邏輯都是基於經典的ARIES協議，也就是基於undo日誌+redo日誌的來進行故障恢復。redo日誌是物理日誌，一般採用WAL(Write-Ahead-Logging)機制，所以也稱redo日誌為wal日誌，redo日誌記錄了所有數據的變更，undo日誌是邏輯日誌，記錄了所有操作的前鏡像，方便異常時進行回滾。用戶在提交事務時，只要確保寫redo日誌成功即可，並不需要對應的數據頁也實時落盤，這套機制的基本思想是利用空間換時間，用戶事務的更新實際上在數據頁和redo日誌中記錄了兩份，傳統的數據庫存儲引擎都是基於B+Tree來組織數據頁，因此刷數據頁是離散小塊IO，而寫redo是順序IO，對磁盤介質更友好，而且OLTP場景下，業務對RT(ResponseTime)也比較敏感，所以這套機制非常流行。

redo日誌是保證數據不丟的關鍵因素，而且每個事務在提交時，都需要寫redo日誌，可想而知這塊資源競爭是非常激烈的。這個問題是所有基於WAL機制的數據庫系統個的共性問題，下文的討論以MySQL為例，並以此說明MySQL8.0在這塊的優化。

最初的redo日誌機制

在MySQL的日誌系統中，這裡討論的是InnoDB引擎，mtr(mini-transaction)是最小事務單位，一個用戶事務會對應若干個mtr，mtr保證內部操作的原子性，比如B+Tree分裂操作，必需在一個mtr中。用戶執行操作時，會同時更新數據頁和寫redo日誌，mtr是redo日誌的載體，存在每個會話的私有變量中。mtr提交時，會將本地redo日誌拷貝到全局的log_buffer中，為了保證日誌有序性，需要加鎖來訪問log_buffer，這把鎖就是log_sys_t::mutex，所以這個鎖競爭非常激烈。在這個鎖保護下，除了要將本地日誌拷貝到全局buffer，還需要將數據頁加入了flush_list，供後台線程刷臟，輔助數據庫檢查點持續往前推進。檢查點一方面能控制全局的redo日誌文件大小，讓日誌具備循環復用的能力；另一方面，也能提高故障恢復速度。因為故障恢復的本質就是利用落盤的redo日誌來恢復沒有落盤的數據頁。所以最開始(MySQL5.1)只有一把鎖，大並發場景下，這個鎖競爭非常激烈，MySQL在多核系統下也無法提升性能。

拆分log_sys_t::mutex

既然鎖競爭壓力大，那麼最直觀的想法就是拆鎖。首先按功能拆分，剛剛說到，在mutex保護下，做了兩件事，一件是拷貝本地日誌到全局log_buffer；另一件事是將事務修改的page加入到flush_list。日誌系統將這兩件事解耦，引入了log_sys_t::flush_order_mutex，減少log_sys_t::mutex的持鎖時間。將本地日誌拷貝到log_buffer後，就可以釋放log_sys_t::mutex，這樣拷貝日誌的線程和處理flush_list的線程就可以並發起來。

除了這個，日誌系統還引入了雙log_buffer機制，這個主要是為了解決全局log_buffer的讀寫並發問題。一個buffer用於拷貝日誌到log_buffer，另一個log_buffer則用於讀取，寫入到日誌文件。當需要讀log_buffer時，則可以切換log_buffer的角色，這樣就消除了寫日誌文件帶來的訪問log_buffer鎖競爭。

但是，拆分完鎖後，多個用戶線程仍然需要在log_sys_t::mutex保護下，串行寫log_buffer，由於memcpy操作比較重，所以這個鎖競爭仍然非常激烈，需要優化。

消除log_sys_t::mutex

為了解決log_sys_t::mutex並發問題，MySQL 8.0引入了新的log_buffer機制，藉助於lock_free的link_buf數據結構，利用原子變量來進行預佔位，這樣多個線程就能並發寫redo，這種機制帶來了一個空洞問題，因為寫日誌速度不一樣，可能導致後佔位(lsn較大)的線程先寫完。但是我們寫日誌線程肯定是不能將帶有空洞的buffer寫到日誌文件，因此會維護一個滑動窗口，即最小的連續的lsn：buf_ready_for_write_lsn。寫日誌線程會不斷的檢查 link_buf變量recent_written，然後寫日誌，推進buf_ready_for_write_lsn。

前面我們提到了系統中有兩把鎖，log_sys_t::mutex和log_sys_t::flush_order_mutex，通過佔位方式，解決了寫log_buffer的問題，那麼如何解決將臟頁有序加入到flush_list的問題呢？MySQL 8.0實現中仍然藉助於link_buf數據結構，原來要求是加入flush_list的數據頁的oldest_modification_lsn一定是遞增的。這裡順便說下oldest_modification_lsn的含義，oldest_modification_lsn是指page第一次被修改後，mtr在log_sys_t中分配的lsn，即使這個page在flush下去之前，又在內存中被修改過N次，仍然以第一次修改的lsn為準，這樣做的目的是，確保數據頁內存的修改與檢查點推進能對應上，避免檢查點推進了，但對應的臟頁可能還未刷盤，造成數據丟失問題。

由於是並發亂序寫log_buffer，那麼無法保證按lsn遞增有序加入到flush_list，也就無法推進檢查點。MySQL 8.0通過限制大於一定閥值L的lsn加入到flush_list做為權衡，假設當前flush_list的lsn最大值為M，那麼只有在M值與當前線程lsn相差範圍在L以內時，才將臟頁寫入flush_list。同樣的，推進M，也依賴於link_buf變量recent_closed。這種策略本質上放寬了之前對於flush_list中對於LSN全局有序的限制到L範圍內的有序。

除了日誌系統變成lock free，MySQL8.0還將寫日誌線程從用戶線程中拆分出來，有單獨的log writer線程和log flusher後台線程來處理寫日誌和sync日誌。原來的寫日誌方式是，大家隨機group-commit，由一個線程負責write/flush日誌，其它線程等待，這種模式下group的大小比較隨機。拆分後，處理更靈活，batch大小也更好控制，而且對於flush_log_at_trx_commit!=1的場景，只需要等log writer的通知即可。

總結

從MySQL日誌系統優化的演進過程來看，始終是圍繞鎖log_sys_t::mutex展開。從最初的按功能拆分出log_sys_t::flush_order_mutex，到按讀寫拆分實現為雙log_buffer，以及最新的MySQL 8.0利用無鎖機制徹底去掉這把鎖，顯然MySQL的並發能力是越來越強的。這種優化“套路”其實是比較樸素通用的，對於一個新的系統，通過一把大鎖能簡化並發邏輯，優先保證正確性。在系統慢慢演進過程中，我們可以按功能拆分鎖，緩解鎖衝突壓力；如果某把鎖處於核心鏈路，而且又成為瓶頸，那麼再想辦法繼續拆，或者實現為無鎖，徹底解決並發衝突問題，目的只有一個就是充分利用多核CPU資源，然線程多幹活，減少響應時間的同時，拉高吞吐量，而不是都等待空閑着。文章中並沒有涉及更多關於MySQL8.0日誌系統優化的細節，官方文檔已經寫地足夠好，大家可以詳細看看。

參考文檔

https://mysqlserverteam.com/mysql-8-0-new-lock-free-scalable-wal-design/

http://mysql.taobao.org/monthly/2018/07/01/

https://yq.aliyun.com/articles/592215?utm_content=m_49932