前言：

前面文章講述了 MySQL 系統(tǒng)中常見的幾種日志，其實還有事務(wù)相關(guān)日志 redo log 和 undo log 沒有介紹。相對于其他幾種日志而言， redo log 和 undo log 是更加神秘，難以觀測的。本篇文章將主要介紹這兩類事務(wù)日志的作用及運維方法。

1.重做日志（redo log）

我們都知道，事務(wù)的四大特性里面有一個是 持久性 ，具體來說就是只要事務(wù)提交成功，那么對數(shù)據(jù)庫做的修改就被永久保存下來了，不可能因為任何原因再回到原來的狀態(tài)。那么 MySQL 是如何保證一致性的呢？最簡單的做法是在每次事務(wù)提交的時候，將該事務(wù)涉及修改的數(shù)據(jù)頁全部刷新到磁盤中。但是這么做會有嚴重的性能問題，主要體現(xiàn)在兩個方面：

• 因為 Innodb 是以頁為單位進行磁盤交互的，而一個事務(wù)很可能只修改一個數(shù)據(jù)頁里面的幾個字節(jié)，這個時候?qū)⑼暾臄?shù)據(jù)頁刷到磁盤的話，太浪費資源了。
• 一個事務(wù)可能涉及修改多個數(shù)據(jù)頁，并且這些數(shù)據(jù)頁在物理上并不連續(xù)，使用隨機 IO 寫入性能太差。
  

因此 MySQL 設(shè)計了 redo log ，具體來說就是只記錄事務(wù)對數(shù)據(jù)頁做了哪些修改，這樣就能完美地解決性能問題了(相對而言文件更小并且是順序IO)。

redo log 包括兩部分：一個是內(nèi)存中的日志緩沖（redo log buffer），另一個是磁盤上的日志文件（redo log file）。MySQL 每執(zhí)行一條 DML 語句，先將記錄寫入 redo log buffer ，后續(xù)某個時間點再一次性將多個操作記錄寫到 redo log file 。

默認情況下，redo log 在磁盤上由名為 ib_logfile0 和 ib_logfile1 的兩個物理文件展示。redo log 相關(guān)參數(shù)簡單介紹如下：

• innodb_log_files_in_group：redo log 文件的個數(shù)，命名方式如：ib_logfile0，iblogfile1... iblogfilen。默認2個，最大100個。
• innodb_log_file_size：單個 redo log 文件設(shè)置大小，默認值為 48M，最大值為512G，注意最大值指的是整個 redo log 系列文件之和，即（innodb_log_files_in_group * innodb_log_file_size ）不能大于最大值512G。
• innodb_log_group_home_dir：指定 redo log 文件組所在的路徑，默認./ ，表示在數(shù)據(jù)庫的數(shù)據(jù)目錄下。
• innodb_log_buffer_size：redo log buffer 大小，默認16M。延遲事務(wù)日志寫入磁盤，把 redo log 放到該緩沖區(qū)，然后根據(jù) innodb_flush_log_at_trx_commit 參數(shù)的設(shè)置，再把日志從 buffer 中 flush 到磁盤中。
• innodb_flush_log_at_trx_commit：控制 redo log 刷新到磁盤的策略，默認為1。值為1，每次 commit 都會把 redo log 從 redo log buffer 寫入到 system ，并 fsync 刷新到磁盤文件中。值為2，每次事務(wù)提交時 MySQL 會把日志從 redo log buffer 寫入到 system ，但只寫入到 file system buffer，由系統(tǒng)內(nèi)部來 fsync 到磁盤文件。如果數(shù)據(jù)庫實例 crash ，不會丟失 redo log，但是如果服務(wù)器 crash，由于 file system buffer 還來不及 fsync 到磁盤文件，所以會丟失這一部分的數(shù)據(jù)。值為0，表示事務(wù)提交時不進行寫入 redo log 操作，這個操作僅在 master thread 中完成，而在 master thread 中每1秒進行一次重做日志的 fsync 操作，因此實例 crash 最多丟失1秒鐘內(nèi)的事務(wù)。
  

更改 redo log 及其 buffer 大小是需要重啟數(shù)據(jù)庫實例的，建議初始化時做好評估?？梢赃m當(dāng)加大 redo log 組數(shù)和大小，特別是你的數(shù)據(jù)庫實例更新比較頻繁的情況下。但也不推薦 redo log 設(shè)置過大。

2.回滾日志（undo log）

undo log 主要用于保證數(shù)據(jù)的原子性，保存了事務(wù)發(fā)生之前的數(shù)據(jù)的一個版本，可以用于回滾。比如一條 INSERT 語句，對應(yīng)一條 DELETE 的 undo log ，對于每個 UPDATE 語句，對應(yīng)一條相反的 UPDATE 的 undo log ，這樣在發(fā)生錯誤時，就能回滾到事務(wù)之前的數(shù)據(jù)狀態(tài)。同時，undo log 也是 MVCC (多版本并發(fā)控制) 實現(xiàn)的關(guān)鍵。

MySQL 5.7 版本中，undo log 默認存放在共享表空間 ibdata 中。也可以在初始化時通過配置參數(shù)改成獨立的文件，簡單介紹幾個 undo log 相關(guān)參數(shù)：

• innodb_max_undo_log_size：控制最大 undo tablespace 文件的大小，當(dāng)啟動了innodb_undo_log_truncate 時，undo tablespace 超過 innodb_max_undo_log_size 閥值時才會去嘗試truncate。該值默認大小為1G，truncate后的大小默認為10M。
• innodb_undo_tablespaces：設(shè)置 undo 獨立表空間個數(shù)，范圍為0-128，5.7版本默認為0，0表示不開啟獨立undo表空間。該參數(shù)只能在最開始初始化 MySQL 實例的時候指定。
• innodb_undo_directory：設(shè)置 undo 表空間的存放目錄，默認數(shù)據(jù)目錄。
• innodb_undo_log_truncate：設(shè)置 undo 表空間是否自動截斷回收。該參數(shù)生效的前提是，已設(shè)置獨立表空間且獨立表空間個數(shù)大于等于2個。
  

undo log 相關(guān)參數(shù)一般很少改動。MySQL 8.0 默認啟用了獨立表空間，可能 undo log 表空間的大小設(shè)置更靈活些。

總結(jié)：

本篇文章主要介紹了 redo log 及 undo log 的作用和相關(guān)參數(shù)設(shè)置，文章寫的比較匆忙，如有錯誤，可以留言指出。關(guān)于這兩類日志更深層次的內(nèi)容，可能筆者功力還不到，未能寫到更加透徹。好了，MySQL 相關(guān)日志的兩篇文章已經(jīng)寫完了，希望各位能學(xué)到一點知識。

最新評論