對于這樣的劇情，想必大家不會陌生：美國大片中拯救世界的英雄，平時看起來跟普通人沒啥區(qū)別，甚至還可能會有點讓人看不上。

但是，關(guān)鍵時刻，卻能爆發(fā)出驚人能量，挽狂瀾于既倒，扶大廈于將傾，拯救世界于危難之中。

今天我們要聊的主角：Redo 日志，也是這樣的平民英雄。

本來 InnoDB 接收到插入、修改、刪除這樣的 DML 語句，以及創(chuàng)建表 & 索引、修改表結(jié)構(gòu)這樣的 DDL 語句，修改 Buffer Pool 中的數(shù)據(jù)頁之后就完事了。

因為要保證數(shù)據(jù)不丟失，事情就變的復雜了，修改了數(shù)據(jù)頁不算完，還要生成 Redo 日志，生成了也不算完，還要把它寫入 Redo 日志文件。

為了方便描述，本文后面會把 Redo 日志文件簡稱為日志文件。

通過以上描述，相信大家能夠發(fā)現(xiàn)，生成 Redo 日志并寫入日志文件，顯然是額外操作，會額外消耗資源。

不惜額外消耗寶貴的服務器資源都要保存下來的東西，肯定不能是個繡花枕頭，那這個有用的枕頭什么時候能派上用場呢？

當然是服務器累了想小憩一下（突然崩潰）的時候了 ^_^。

服務器也不容易，誰還沒有個突然崩潰的時候呢？

說了這么多，是時候確定 Redo 日志的歷史地位了：Redo 日志，在太平日子里，不但是個雞肋，更是個累贅，但是，別把它不當英雄，關(guān)鍵時刻還得靠它拯救數(shù)據(jù)庫。

飯前甜點到此為止，接下來是正餐。

本文內(nèi)容基于 MySQL 8.0.29 源碼。

正文

1、概述

MySQL 8.0 以前，Redo 日志是串行寫入 log buffer 的，多個用戶線程想要同時往 log buffer 里寫日志，那是不行的，必須排隊等待（獲取互斥鎖），拿到互斥鎖之后，才能往 log buffer 里寫日志。

MySQL 8.0 中，串行寫入變?yōu)椴⑿袑懭?，log buffer 由鄉(xiāng)間小道變成了單向 8 車道的高速公路，多個用戶線程可以同時往 log buffer 里寫入 Redo 日志，效率大大提升。

Redo 日志從產(chǎn)生到刷盤，一共會經(jīng)歷 4 個階段（產(chǎn)生、寫 log buffer、寫日志文件、刷盤），本文會用 4 個小節(jié)分別介紹這 4 個階段。

2、Redo 日志產(chǎn)生

以一條非常簡單的插入語句為例，這個語句包含自增列，并且只插入一條記錄，我們假設插入過程中不會造成索引頁分裂，也不會產(chǎn)生溢出頁。

不考慮 Undo 日志產(chǎn)生的 Redo 日志，這樣一條 SQL 語句會包含 2 條 Redo 日志（這 2 條日志會形成一個日志組）：

• 一條日志中保存著表中自增列的最大值（MySQL 8.0 把自增列的值持久化了）。
• 另一條日志中保存著插入記錄各字段的值。

每條日志中還有可能會包含 InnoDB 需要的其它信息。

插入記錄的過程中，會先產(chǎn)生一條 Redo 日志用于記錄表中自增列的最大值，然后插入記錄，再產(chǎn)生另一條 Redo 日志。

Redo 日志并不會每產(chǎn)生一條就馬上寫入 log buffer，而是一組 Redo 日志攢到一起往 log buffer 里寫。

問題來了，產(chǎn)生了一條 Redo 日志不能馬上寫入 log buffer，那怎么辦？

那就需要有一個地方臨時存放日志組中不同時間點產(chǎn)生的日志了，這個地方就是 mtr 中的 m_log 鏈表。

m_log 鏈表是由一個一個 block 組成的鏈表，block 大小為 512 字節(jié)，每產(chǎn)生一條日志，就追加到 m_log 的 block 中，如果一個 block 寫滿了，就再申請一個 block 接著寫。

那 mtr 又是個啥？

mtr 是 Mini-Transaction 的縮寫，是一組不可分隔的操作組成的一個整體，就像前面插入語句的例子中，保存表中自增列的最大值和插入記錄就是一組不可分隔的操作，必須放入一個 mtr。

兩個操作放入一個 mtr，它們的日志也就放在同一個 mtr 中了。這樣就能保證兩個操作產(chǎn)生的 Redo 日志一起寫入 log buffer 和日志文件中。

mtr 的用途可不止打包一組 Redo 日志這么簡單，它還會對 SQL 執(zhí)行過程中 mtr 需要訪問的 Buffer Pool 中的頁加鎖、修改頁中的數(shù)據(jù)、釋放鎖，本文我們只介紹 Redo 日志，對于 mtr 就不再展開了。

還有一個概念需要解釋一下，日志組就是一個 mtr 中的所有日志。

3、寫入 log buffer

mtr 中一組不可分隔的操作都完成之后，就該提交了，mtr 提交過程中要干的第一件事就是把它里面臨時存放的一組 Redo 日志寫入到 log buffer 中。

一個事務中可能會包含多個 mtr，mtr 的提交和事務的提交不是一個概念，不要混淆。

前面說到在 MySQL 8.0 中，往 log buffer 里寫日志不需要排隊等待（獲取互斥鎖），多個用戶線程可以同時寫入。

這個無鎖化設計是通過在 log buffer 中為每個 mtr 中的 Redo 日志預留空間實現(xiàn)的，每個 mtr 都有一段屬于自己的空間，各自往自己專屬的空間內(nèi)寫入日志，相互之間就不影響了。

用戶線程的 mtr 往 log buffer 寫 Redo 日志前，會先獲取一段序列號。

以當前系統(tǒng)中已產(chǎn)生的最大序列號（SN）作為 start_sn，加上本次要往 log buffer 中寫入的 Redo 日志的字節(jié)數(shù)（len），得到 end_sn（end_sn = start_sn + len）。

start_sn ~ end_sn 就是本次要寫入 log buffer 的 Redo 日志的序列號區(qū)間。

獲取 start_sn、end_sn 的過程是原子操作，多個線程之間不會出現(xiàn)沖突，不會獲取到有交叉的序列號區(qū)間。

拿到 start_sn ~ end_sn 只是第一步，還需要進行一次轉(zhuǎn)換，把序列號（SN）轉(zhuǎn)換為日志序列號（LSN），得到一個 LSN 的范圍：start_lsn ~ end_lsn，這個范圍對應著 log_buffer 中為 mtr 即將寫入的 Redo 日志預留的空間。

SN 是截止某個時刻，InnoDB 中實際產(chǎn)生的 Redo 日志字節(jié)數(shù)。

SN 按照 496 字節(jié)拆分，拆分后每 496 字節(jié)，加上 12 字節(jié)的頭信息、4 字節(jié)尾部檢驗碼，得到 512 字節(jié)的 block，經(jīng)過這樣的轉(zhuǎn)換之后，得到的數(shù)字就是 LSN。

至此，寫入日志到 log buffer 的準備工作又往前推進了一步。

但是，別著急，也許還要再等等，如果 log buffer 中剩余空間不夠?qū)懭氘斍?mtr 的 Redo 日志，那就需要等到 log buffer 中的 Redo 日志被寫入日志文件，為當前 mtr 的 Redo 日志騰出空間才行。

這里的寫入日志文件，只是調(diào)用了操作系統(tǒng)的寫文件方法，把 Redo 日志寫入日志文件的操作系統(tǒng)緩沖區(qū)中，日志文件暫時還不會刷新到磁盤上。

那怎么判斷 log buffer 中是否有空間呢？

要回答這個問題，我們需要先介紹一個屬性 log_sys.write_lsn，表示 LSN 小于 log_sys.writen_lsn 的日志都已經(jīng)寫入到日志文件緩沖區(qū)中。

end_sn <= log_sys.write_lsn + innodb_log_buffer_size（默認 16M），就表示 log buffer 中有空間寫入當前 mtr 的 Redo 日志。

如果要等，總不能一直等吧，等到什么時候是個頭呢？

如果需要等待，用戶線程會監(jiān)聽 log.write_events 事件，log buffer 中有空間寫入 Redo 日志之后，當前用戶線程會收到事件通知。

誰會給這些等待的用戶線程發(fā)送事件通知呢？后面會有介紹，請繼續(xù)往下看。

等到 log buffer 中有空間之后，往里面寫入日志就很簡單了，直接把 mtr 中的 Redo 日志拷貝到 log buffer 中就完事了。

寫完之后，還需要根據(jù) mtr 的 start_lsn 在 recent_written.m_links 中找到對應的 SLOT，然后把 mtr 的 end_lsn 寫入這個 SLOT，表示這個 mtr 已經(jīng)把它的全部 Redo 日志寫入 log buffer 了。

如果根據(jù) start_lsn 在 recent_written.m_links 中找到的 SLOT 正在被其它 mtr 使用，當前這個用戶線程會采用循環(huán) + 間隔休眠 20 毫秒的方式，直到 SLOT 可以使用。

前面兩段涉及到 recent_written 的介紹，大家看了可能會覺得一頭霧水，先不要著急，有個模糊印象就行。

因為這兩段邏輯是在寫日志到 log buffer 這個階段發(fā)生的，所以這里必須要提一下露個臉，相當于占個位，但是詳細介紹放到 4. 寫入日志文件小節(jié)更合適。

說完了寫入 Redo 日志到 log buffer，我們回到用戶線程??等待?? log buffer 中有空間寫入它的 Redo 日志，這個等待過程是個躺平的過程，在這個過程中，用戶線程除了等待事件通知，其它事情啥也不干。

在用戶線程看來，等待的過程中歲月靜好，但是，世上本來沒有歲月靜好，它感受到的歲月靜好，無非是因為有人替它負重前行。

誰在負重前行？

那是另一個默默工作的線程，它的名字叫作 log_writer，它是一個搬運工，一個專門把 log buffer 中的 Redo 日志寫入到日志文件的線程。

log_writer 線程只調(diào)用操作系統(tǒng)寫文件方法，把 Redo 日志寫入日志文件，不會刷新到磁盤上，此時，Redo 日志還在日志文件的操作系統(tǒng)緩沖區(qū)中。

接下來，就是 log_writer 線程的主場了。

4、寫入日志文件

log writer 線程把 log buffer 中的 Redo 日志寫入日志文件緩沖區(qū)，寫入的這一段 Redo 日志必須是連續(xù)的，中間不能出現(xiàn)空洞。

上一個步驟中，不同用戶線程可以并行把各自 mtr 中的 Redo 日志寫入 log buffer 中，解決了寫入速度慢的問題，同時也帶來了新問題。

不同用戶線程的 Redo 日志量可能不一樣，有的線程會先寫完，有的線程后寫完，如果某一個范圍內(nèi)，頭部的日志寫完了，尾部的日志也寫完了，中間的日志還沒寫完，這就出現(xiàn)了空洞。

舉個例子，假設有 3 個不同的用戶線程，各有一個 mtr 要提交，我們把這 3 個用戶線程的 mtr 分別叫作 mtr 10、mtr 11、mtr 12。

mtr 10 的 Redo 日志占用 200 字節(jié)，LSN 范圍是 start_lsn(2097252) ~ end_lsn(2097452)。

mtr 11 的 Redo 日志占用 12045 字節(jié)，LSN 范圍是 start_lsn(2097452) ~ end_lsn(2109497)。

mtr 12 的 Redo 日志占用 300 字節(jié)，LSN 范圍是 start_lsn(2109497) ~ end_lsn(2109797)。

每一個 mtr 的 end_lsn 其實是不屬于它的，而是屬于下一個 mtr，是下一個 mtr 的 start_lsn。所以，每個 mtr 的 LSN 范圍是一個左閉右開區(qū)間，例如：mtr 10 [2097252, 2097452)。

mtr 10、mtr 12 的日志比較小，mtr 11 的日志比較大，可能會存在這樣的情況，mtr 10、mtr 12 的日志都已經(jīng)全部寫入 log buffer，mtr 11 的日志只有一部分寫入了 log buffer，中間是存在空洞的。

因為存在空洞，log_writer 線程不能把 mtr 10 ~ 12 的 Redo 日志都寫入日志文件，只能把 mtr 10 的 Redo 日志寫入日志文件。

等到 mtr 11 的 Redo 日志全部寫入 log buffer 之后，才能把 mtr 11 ~ 12 的 Redo 日志一起寫入日志文件。

那它怎么知道截止到哪個位置的日志是連續(xù)的，可以寫入日志文件的呢？

也許我們都能很快想到用一個變量把這個位置記錄下來就好了。

沒錯，InnoDB 也是這么干的，全局日志對象（log_sys）中，有一個 recent_written 屬性，這個屬性也是個對象，它有一個屬性 m_tail（log_sys.recent_written.m_tail），用來記錄 log buffer 中小于哪個 LSN 的日志都是連續(xù)的。

知道了用什么記，現(xiàn)在有個關(guān)鍵問題，那就是怎么記？

recent_written 對象，有個屬性 m_links（recent_written.m_links），這是個數(shù)組，默認有 1048576 個元素，每個元素是一個 SLOT，每個 SLOT 占用 8 字節(jié)，總共占用 8M 內(nèi)存空間。

m_links 的每個 SLOT 對應 log buffer 中的一個 LSN，每個用戶線程的 mtr 往 log buffer 中寫入它的全部 Redo 日志之后，會根據(jù) start_lsn 在 m_links 中找到一個 SLOT，并把 end_lsn 寫入這個 SLOT。

還是以前面的 mtr 10 ~ 12 為例，當 mtr 10 把它的所有 Redo 日志全部寫入 log buffer 之后，根據(jù) start_lsn(2097252) 找到對應的 SLOT 并寫入 end_lsn(2097452)。

SLOT 下標 = start_lsn(2097252) % SLOT 數(shù)量(1048576) = 100。

m_links[100] = end_lsn(2097452)，m_links[101 ~ 299] 對應著 LSN 2097253 ~ 2097451，也屬于 mtr 10 的范圍，不過這個區(qū)間只是用來占位的，mtr 10 并不會往其中的 SLOT 寫入 LSN。

重要說明：實際上，因為 m_links 被當作環(huán)形結(jié)構(gòu)循環(huán)、重復使用，每個 SLOT 都有可能曾經(jīng)被其它 mtr 寫入過 end_lsn。

對于 mtr 10 來說，除了 start_lsn 對應的 SLOT（m_links[100]）的值是 end_lsn(2097452) 之外，其它 SLOT（m_links[101 ~ 299]）的值可能是 0，也可能是之前的某個 mtr 寫入的 end_lsn。

如果 SLOT 的值是之前的某個 mtr 寫入的 end_lsn，這個 end_lsn 一定是小于等于 mtr 10 的 start_lsn 的。

當 mtr 12 把它的所有 Redo 日志全部寫入 log buffer 之后，根據(jù) start_lsn(2109497) 找到對應的 SLOT 并寫入 end_lsn(2109797)。

SLOT 下標 = start_lsn(2109497) % SLOT 數(shù)量(1048576) = 12345。

m_links[12345] = end_lsn(2109797)，m_links[12346 ~ 12644] 對應著 LSN 2109498 ~ 2109796，也屬于 mtr 12 的范圍，這個區(qū)間內(nèi) SLOT 的值可能為 0 或者小于等于 start_lsn(2109497) 的數(shù)字（具體原因可以參照 mtr 10 的說明）。

此時，mtr 11 的 Redo 日志還沒有全部寫入 log buffer，m_links[300 ~ 12344] 對應著 LSN 2097452 ~ 2109496，屬于 mtr 11 的范圍，這個區(qū)間內(nèi) SLOT 的值可能為 0 或小于等于 start_lsn(2097452) 的數(shù)字（具體原因可以參照 mtr 10 的說明）。

說完了 mtr 10 ~ 12 的狀態(tài)，接下來就要正式介紹 Redo 日志寫入日志文件的關(guān)鍵步驟了：根據(jù) recent_written.m_links 找到 log buffer 中連續(xù)的日志區(qū)間。

先來回憶一下：

• recent_written.m_tail?，表示 log buffer 中小于 recent_written.m_tail 的日志都是連續(xù)的。
• log_sys.write_lsn?， 表示 log buffer 中小于 log_sys.write_lsn 的日志都已經(jīng)寫入日志文件了。

假設，此時 recent_written.m_tail = 2097252，這是 mtr 10 的 start_lsn，表示 mtr 10 之前的 mtr 往 log buffer 中寫入的 Redo 日志已經(jīng)是連續(xù)的了。

log_writer 線程接下來從 m_tail 對應的 LSN（2097252）開始，尋找更大范圍的連續(xù)日志區(qū)間。

計算 m_tail 對應的 SLOT 下標 = m_tail(2097252) % SLOT 數(shù)量(1048576) = 100。

讀取 SLOT 100（下標為 100 的 SLOT）的值，得到 2097452，這是 mtr 10 的 end_lsn，也是 mtr 11 的 start_lsn，說明 mtr 10 的日志已寫入 log buffer。

LSN < 2097452 的區(qū)間，Redo 日志都是連續(xù)的了，更新 m_tail 的值，recent_written.m_tail = 2097452。

繼續(xù)尋找，計算 m_tail 對應的 SLOT 下標 = m_tail(2097452) % SLOT 數(shù)量(1048576) = 300。

讀取 SLOT 300 的值，得到 0，說明 mtr 11 還沒有把 Redo 日志全部寫入 log buffer 了，本次尋找更大范圍的連續(xù)日志區(qū)間結(jié)束，m_tail 保持為 2097452 不變。

log_writer 線程可以把 log buffer 中 LSN < m_tail(2097452) 的 Redo 日志寫入到日志文件，寫完之后，更新 log_sys.write_lsn 的值，log_sys.write_lsn = 2097452。

然后，log_writer 線程或 log_write_notifier 線程會通知正在等待往 log buffer 中 LSN < m_tail(2097452) 這個區(qū)間寫 Redo 日志的用戶線程，告訴它們可以寫 Redo 日志了。

為了減輕 log_writer 線程的負擔，通知用戶線程這個邏輯做了區(qū)分：

如果只有一個用戶線程正在等待往 log buffer 中 LSN < m_tail(2097452) 區(qū)間寫 Redo 日志，log_writer 線程順手就通知這個用戶線程了。

如果有多個用戶線程正在等待往  log buffer 中 LSN < m_tail(2097452) 區(qū)間寫 Redo 日志，log_writer 線程會讓 log_write_notifier 線程去通知等待這個范圍可寫的所有用戶線程。

3. 寫入 log buffer 小節(jié)說過，如果用戶線程需要等待 log buffer 中有空間寫入它的 Redo 日志，這個用戶線程會監(jiān)聽 log.write_events 事件，log_writer & log_write_notifier 線程就是通過這個事件通知用戶線程的。

實際上，用戶線程監(jiān)聽的是 log.write_events[slot]，slot 是對 mtr 的 start_lsn 取模計算得到的，計算公式是這樣的：slot = start_lsn % recent_written.m_links 的 SLOT 數(shù)量（默認 1048576）。

監(jiān)聽到具體的 slot 上是為了保證每個用戶線程只會接收到 log.write_events 事件中和自己有關(guān)的通知。

過了一小會，log_writer 線程又要開始工作了，此時，mtr 11 中的全部 Redo 日志都寫入 log buffer 了。

上次結(jié)束時，recent_written.m_tail = 2097452，其對應的 SLOT 下標為 300，這次從 SLOT 300 開始繼續(xù)尋找。

讀取 SLOT 300 的值，得到 2109497，這是 mtr 11 的 end_lsn，也是 mtr 12 的 start_lsn，說明 LSN < 2109497 的區(qū)間，Redo 日志都是連續(xù)的了，更新 m_tail 的值，recent_written.m_tail = 2109497。

繼續(xù)尋找，計算 m_tail 對應的 SLOT 下標 = m_tail(2109497) % SLOT 數(shù)量(1048576) = 12345。

讀取 SLOT 12345 的值，得到 2109797，這是 mtr 12 的 end_lsn，也是 mtr 12 之后的下一個 mtr 的 start_lsn，說明 LSN < 2109797 的區(qū)間，Redo 日志都是連續(xù)的了，更新 m_tail 的值， recent_written.m_tail = 2109797。

繼續(xù)尋找，計算 m_tail 對應的 SLOT 下標 = m_tail(2109797) % SLOT 數(shù)量(1048576) = 12645。

讀取 SLOT 12645 的值，得到 0，說明 Redo 日志連續(xù)的區(qū)間到這里暫時結(jié)束，m_tail 保持為 2109797 不變。

log_writer 線程可以把 log buffer 中 LSN < m_tail(2109797) 的 Redo 日志寫入到日志文件了，寫完之后，更新 log_sys.write_lsn 的值，log_sys.write_lsn = 2109797。

然后，log_writer 線程或 log_write_notifier 線程會觸發(fā) log.write_events 事件，通知正在等待往 LSN < m_tail(2109797) 區(qū)間內(nèi)寫 Redo 日志的用戶線程，告訴它們可以寫 Redo 日志了。

5、日志文件刷盤

Redo 日志從 log buffer 寫入日志文件中，并不是直接就寫到磁盤文件中了，而是會先進入日志文件在操作系統(tǒng)的緩沖區(qū)中，還需要經(jīng)過刷盤操作才能最終寫到磁盤上的日志文件中，成為持久化的日志。

Redo 日志文件刷盤，也是由專門的線程完成的，這個線程是 log_flusher。

log_flusher 線程的常規(guī)工作是大概每秒執(zhí)行一次刷盤操作。

全局日志對象（log_sys）中有一個屬性 flushed_to_disk_lsn 表示小于 log_sys.flushed_to_disk_lsn 的 Redo 日志都已經(jīng)刷新到磁盤上的日志文件中了。

前面我們還提到了另一個屬性 log_sys.write_lsn，表示 log buffer 中小于 log_sys.write_lsn 的日志都已經(jīng)寫入日志文件了。

每次執(zhí)行刷盤操作時，對比這兩個屬性的值，就能判斷出來日志文件緩沖區(qū)中是不是有新的 Redo 日志需要刷盤。

如果 log_sys.write_lsn 大于 log_sys.flushed_to_disk_lsn，說明需要刷盤，否則本次不需要執(zhí)行刷盤操作，log_flusher 線程可以愉快的躺平大概 1s 左右，然后等待下一次時間到了，再進行同樣的邏輯判斷，確定是否需要刷盤。

不出意外的話，log_flusher 線程就是這么簡單平凡，日復一日，年復一年的機械單調(diào)的工作著。

但是，這顯然不符合劇情發(fā)展，單調(diào)的故事中總是會時不時出現(xiàn)點刺激的劇情。

log_flusher 線程除了常規(guī)的每秒執(zhí)行一次刷盤操作，還會監(jiān)聽一個事件：log.flusher_event，通過這個事件和外界保持聯(lián)系，接受外部刺激。

我們來看一個帶給 log_flusher 線程刺激場景：

innodb_flush_log_at_trx_commit = 1 時，事務每次提交的時候，都心急火燎的，不可能心平氣和的等著 log_flusher 每秒執(zhí)行一次刷盤操作，必須讓 log_flusher 立馬起來干活（事務會觸發(fā) log.flusher_event 事件），把事務中產(chǎn)生的 Redo 日志刷盤，然后，事務才能向客戶端交差。

innodb_flush_log_at_trx_commit = 2 時，事務心急火燎的對象就不是 log_flusher 線程了，而是 log_writer 線程，因為這種場景下，事務只需要等待 log_writer 線程把它的 Redo 日志寫入日志文件緩沖區(qū)就可以了，不需要等待刷盤。

事務催促 log_flusher 執(zhí)行刷盤操作之后，會等待刷盤操作完成。等待過程是通過監(jiān)聽 log.flush_events[slot] 事件實現(xiàn)的。

slot 是對事務中最后一個 mtr（一個事務可以包含多個 mtr）的 end_lsn 取模計算得到的，計算公式是這樣的：slot = end_lsn % recent_written.m_links 的 SLOT 數(shù)量（默認 1048576）。

slot 的作用是保證每個用戶線程只會接收到 log.flush_events 事件中和自己有關(guān)的通知。

刷盤操作完成后，log_flusher 線程或 log_flush_notifier 線程會通知正在等待 LSN < m_tail(2097452) 這個區(qū)間內(nèi)的 Redo 日志刷盤的用戶線程。

為了減輕 log_flusher 線程的負擔，通知用戶線程這個邏輯做了區(qū)分：

如果只有一個用戶線程正在等待本次刷盤結(jié)果，log_flusher 線程順手就通知這個用戶線程了。

如果有多個用戶線程正在等待本次刷盤結(jié)果，log_flusher 線程會讓 log_flush_notifier 線程去通知等待本次刷盤結(jié)果的所有用戶線程。

6、總結(jié)

Redo 日志是以日志組為單位寫入 log buffer 和日志文件的，每個日志組的 Redo 日志都來源于一個 mtr。

多個用戶線程的 mtr 以無鎖的方式并行往 log buffer 里寫入 Redo 日志，只需要寫入之前計算出來 mtr 中 Redo 日志的 LSN 范圍，通過這個 LSN 范圍在 log buffer 中鎖定一段區(qū)間，多個用戶線程鎖定的區(qū)間不一樣，不會出現(xiàn)沖突。

log_writer 線程把已經(jīng)寫入 log buffer 的 Redo 日志寫入日志文件，需要保證 Redo 日志是連續(xù)的，InnoDB 用 log_sys.recent_written 對象中的 m_links 數(shù)組、m_tail 屬性來輔助 log_writer 線程找到連續(xù)的日志區(qū)間。

log_writer 線程把 log buffer 中的 Redo 日志寫入日志文件之后，會通知等待 log buffer 為它騰出空間的用戶線程，或者讓 log_write_notifier 線程通知用戶線程。

log_flusher 線程每秒執(zhí)行一次刷盤操作，同時還監(jiān)聽了 log.flusher_event 事件，用于接收外部刺激，觸發(fā)它在周期性刷盤工作的時候也能夠更及時的刷盤。

如果 log_sys.write_lsn 大于 log_sys.flushed_to_disk_lsn 說明需要執(zhí)行刷盤操作，否則不需要。

log_flusher 線程執(zhí)行完刷盤操作之后，也會通知等待刷盤操作完成的用戶線程，或者讓 log_flush_notifier 線程通知用戶線程。

最后，放上一張整體流程圖，希望能夠有助于大家理解 Redo 日志刷盤的整體流程。

本文轉(zhuǎn)載自微信公眾號「一樹一溪」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系一樹一溪公眾號。