MySQL8.0 redo日誌系統優化

背景

如今主流的數據庫系統的故障恢復邏輯都是基於經典的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