天天看點
傳回

MySQL 日志系統之 redo log 和 binlog日志子產品：binlog兩階段送出（2PC）日志相關問題總結

之前我們了解了一條查詢語句的執行流程，并介紹了執行過程中涉及的處理子產品。一條查詢語句的執行過程一般是經過連接配接器、分析器、優化器、執行器等功能子產品，最後到達存儲引擎。

那麼，一條 SQL 更新語句的執行流程又是怎樣的呢？

首先我們建立一個表 T，主鍵為 id，建立語句如下：

CREATE TABLE `T` (
  `ID` int(11) NOT NULL,
  `c` int(11) DEFAULT NULL,
  PRIMARY KEY (`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

插入一條資料：

INSERT INTO T VALUES ('2', '1');

如果要将 ID=2 這一行的 c 的值加 1，SQL 語句為：

UPDATE T SET c = c + 1 WHERE ID = 2;

前面介紹過 SQL 語句基本的執行鍊路，這裡把那張圖拿過來。因為，更新語句同樣會走一遍查詢語句走的流程。

MySQL 日志系統之 redo log 和 binlog日志子產品：binlog兩階段送出（2PC）日志相關問題總結
  1. 通過連接配接器，用戶端與 MySQL 建立連接配接
  2. update 語句會把 T 表上的所有查詢緩存結果清空
  3. 分析器會通過詞法分析和文法分析識别這是一條更新語句
  4. 優化器會決定使用 ID 這個索引（聚簇索引）
  5. 執行器負責具體執行，找到比對的一行，然後更新
  6. 更新過程中還會涉及 redo log（重做日志）和 binlog（歸檔日志）的操作

其中，這兩種日志預設在資料庫的 data 目錄下，redo log 是 ib_logfile0 格式的，binlog 是 xxx-bin.000001 格式的。

接下來讓我們分别去研究下日志子產品中的 redo log 和 binlog。

日志子產品：redo log

在 MySQL 中，如果每一次的更新操作都需要寫進磁盤，然後磁盤也要找到對應的那條記錄，然後再更新，整個過程 IO 成本、查找成本都很高。為了解決這個問題，MySQL 的設計者就采用了日志（redo log）來提升更新效率。

而日志和磁盤配合的整個過程，其實就是 MySQL 裡的 WAL 技術，WAL 的全稱是 Write-Ahead Logging，它的關鍵點就是先寫日志，再寫磁盤。

具體來說，當有一條記錄需要更新的時候，InnoDB 引擎就會先把記錄寫到 redo log（redolog buffer）裡面，并更新記憶體（buffer pool），這個時候更新就算完成了。同時，InnoDB 引擎會在适當的時候（如系統空閑時），将這個操作記錄更新到磁盤裡面（刷髒頁）。

redo log 是 InnoDB 存儲引擎層的日志，又稱重做日志檔案，redo log 是循環寫的，redo log 不是記錄資料頁更新之後的狀态，而是記錄這個頁做了什麼改動。

redo log 是固定大小的，比如可以配置為一組 4 個檔案，每個檔案的大小是 1GB，那麼日志總共就可以記錄 4GB 的操作。從頭開始寫，寫到末尾就又回到開頭循環寫，如下圖所示。

MySQL 日志系統之 redo log 和 binlog日志子產品：binlog兩階段送出（2PC）日志相關問題總結

圖中展示了一組 4 個檔案的 redo log 日志，checkpoint 是目前要擦除的位置，擦除記錄前需要先把對應的資料落盤（更新記憶體頁，等待刷髒頁）。write pos 到 checkpoint 之間的部分可以用來記錄新的操作，如果 write pos 和 checkpoint 相遇，說明 redolog 已滿，這個時候資料庫停止進行資料庫更新語句的執行，轉而進行 redo log 日志同步到磁盤中。checkpoint 到 write pos 之間的部分等待落盤（先更新記憶體頁，然後等待刷髒頁）。

有了 redo log 日志，那麼在資料庫進行異常重新開機的時候，可以根據 redo log 日志進行恢複，也就達到了 crash-safe。

redo log 用于保證 crash-safe 能力。innodb_flush_log_at_trx_commit 這個參數設定成 1 的時候，表示每次事務的 redo log 都直接持久化到磁盤。這個參數建議設定成 1，這樣可以保證 MySQL 異常重新開機之後資料不丢失。

日志子產品：binlog

MySQL 整體來看，其實就有兩塊：一塊是 Server 層，它主要做的是 MySQL 功能層面的事情；還有一塊是引擎層，負責存儲相關的具體事宜。redo log 是 InnoDB 引擎特有的日志，而 Server 層也有自己的日志，稱為 binlog（歸檔日志）。

binlog 屬于邏輯日志，是以二進制的形式記錄的是這個語句的原始邏輯，依靠 binlog 是沒有 crash-safe 能力的。

binlog 有兩種模式，statement 格式的話是記 sql 語句，row 格式會記錄行的内容，記兩條，更新前和更新後都有。

sync_binlog 這個參數設定成 1 的時候，表示每次事務的 binlog 都持久化到磁盤。這個參數也建議設定成 1，這樣可以保證 MySQL 異常重新開機之後 binlog 不丢失。

為什麼會有兩份日志呢？

因為最開始 MySQL 裡并沒有 InnoDB 引擎。MySQL 自帶的引擎是 MyISAM，但是 MyISAM 沒有 crash-safe 的能力，binlog 日志隻能用于歸檔。而 InnoDB 是另一個公司以插件形式引入 MySQL 的，既然隻依靠 binlog 是沒有 crash-safe 能力的，是以 InnoDB 使用另外一套日志系統——也就是 redo log 來實作 crash-safe 能力。

redo log 和 binlog 差別：

  1. redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 層實作的，所有引擎都可以使用。
  2. redo log 是實體日志，記錄的是在某個資料頁上做了什麼修改；binlog 是邏輯日志，記錄的是這個語句的原始邏輯。
  3. redo log 是循環寫的，空間固定會用完；binlog 是可以追加寫入的。追加寫是指 binlog 檔案寫到一定大小後會切換到下一個，并不會覆寫以前的日志。

有了對這兩個日志的概念性了解後，再來看執行器和 InnoDB 引擎在執行這個 update 語句時的内部流程。

  1. 執行器先找引擎取 ID=2 這一行。ID 是主鍵，引擎直接用樹搜尋找到這一行。如果 ID=2 這一行所在的資料頁本來就在記憶體中，就直接傳回給執行器；否則，需要先從磁盤讀入記憶體，然後再傳回。
  2. 執行器拿到引擎給的行資料，把這個值加上 1，比如原來是 N，現在就是 N+1，得到新的一行資料，再調用引擎接口寫入這行新資料。
  3. 引擎将這行新資料更新到記憶體（InnoDB Buffer Pool）中，同時将這個更新操作記錄到 redo log 裡面，此時 redo log 處于 prepare 狀态。然後告知執行器執行完成了，随時可以送出事務。
  4. 執行器生成這個操作的 binlog，并把 binlog 寫入磁盤。
  5. 執行器調用引擎的送出事務接口，引擎把剛剛寫入的 redo log 改成送出（commit）狀态，更新完成。

下圖為 update 語句的執行流程圖，圖中灰色框表示是在 InnoDB 内部執行的，綠色框表示是在執行器中執行的。

MySQL 日志系統之 redo log 和 binlog日志子產品：binlog兩階段送出（2PC）日志相關問題總結

其中将 redo log 的寫入拆成了兩個步驟：prepare 和 commit，這就是兩階段送出（2PC）。

兩階段送出（2PC）

MySQL 使用兩階段送出主要解決 binlog 和 redo log 的資料一緻性的問題。

redo log 和 binlog 都可以用于表示事務的送出狀态，而兩階段送出就是讓這兩個狀态保持邏輯上的一緻。下圖為 MySQL 二階段送出簡圖：

MySQL 日志系統之 redo log 和 binlog日志子產品：binlog兩階段送出（2PC）日志相關問題總結

兩階段送出原理描述:

  1. InnoDB redo log 寫盤，InnoDB 事務進入 prepare 狀态。
  2. 如果前面 prepare 成功，binlog 寫盤，那麼再繼續将事務日志持久化到 binlog，如果持久化成功，那麼 InnoDB 事務則進入 commit 狀态(在 redo log 裡面寫一個 commit 記錄)

備注: 每個事務 binlog 的末尾，會記錄一個 XID event，标志着事務是否送出成功，也就是說，recovery 過程中，binlog 最後一個 XID event 之後的内容都應該被 purge。

日志相關問題

怎麼進行資料恢複？

binlog 會記錄所有的邏輯操作，并且是采用追加寫的形式。當需要恢複到指定的某一秒時，比如今天下午二點發現中午十二點有一次誤删表，需要找回資料，那你可以這麼做：

  • 首先，找到最近的一次全量備份，從這個備份恢複到臨時庫
  • 然後，從備份的時間點開始，将備份的 binlog 依次取出來，重放到中午誤删表之前的那個時刻。

這樣你的臨時庫就跟誤删之前的線上庫一樣了，然後你可以把表資料從臨時庫取出來，按需要恢複到線上庫去。

redo log 和 binlog 是怎麼關聯起來的?

redo log 和 binlog 有一個共同的資料字段，叫 XID。崩潰恢複的時候，會按順序掃描 redo log：

  • 如果碰到既有 prepare、又有 commit 的 redo log，就直接送出；
  • 如果碰到隻有 parepare、而沒有 commit 的 redo log，就拿着 XID 去 binlog 找對應的事務。

MySQL 怎麼知道 binlog 是完整的?

一個事務的 binlog 是有完整格式的：

  • statement 格式的 binlog，最後會有 COMMIT
  • row 格式的 binlog，最後會有一個 XID event

在 MySQL 5.6.2 版本以後，還引入了 binlog-checksum 參數，用來驗證 binlog 内容的正确性。對于 binlog 日志由于磁盤原因，可能會在日志中間出錯的情況，MySQL 可以通過校驗 checksum 的結果來發現。是以，MySQL 是有辦法驗證事務 binlog 的完整性的。

redo log 一般設定多大？

redo log 太小的話，會導緻很快就被寫滿，然後不得不強行刷 redo log，這樣 WAL 機制的能力就發揮不出來了。

如果是幾個 TB 的磁盤的話，直接将 redo log 設定為 4 個檔案，每個檔案 1GB。

資料寫入後的最終落盤，是從 redo log 更新過來的還是從 buffer pool 更新過來的呢？

實際上，redo log 并沒有記錄資料頁的完整資料，是以它并沒有能力自己去更新磁盤資料頁，也就不存在由 redo log 更新過去資料最終落盤的情況。

  1. 資料頁被修改以後，跟磁盤的資料頁不一緻，稱為髒頁。最終資料落盤，就是把記憶體中的資料頁寫盤。這個過程與 redo log 毫無關系。
  2. 在崩潰恢複場景中，InnoDB 如果判斷到一個資料頁可能在崩潰恢複的時候丢失了更新，就會将它讀到記憶體，然後讓 redo log 更新記憶體内容。更新完成後，記憶體頁變成髒頁，就回到了第一種情況的狀态。

redo log buffer 是什麼？是先修改記憶體，還是先寫 redo log 檔案？

在一個事務的更新過程中，日志是要寫多次的。比如下面這個事務：

begin;
INSERT INTO T1 VALUES ('1', '1');
INSERT INTO T2 VALUES ('1', '1');
commit;

這個事務要往兩個表中插入記錄，插入資料的過程中，生成的日志都得先儲存起來，但又不能在還沒 commit 的時候就直接寫到 redo log 檔案裡。

是以就需要 redo log buffer 出場了，它就是一塊記憶體，用來先存 redo 日志的。也就是說，在執行第一個 insert 的時候，資料的記憶體被修改了，redo log buffer 也寫入了日志。

但是，真正把日志寫到 redo log 檔案，是在執行 commit 語句的時候做的。

以下是我截取的部分 redo log buffer 的源代碼：

/** redo log buffer */
struct log_t{
    char        pad1[CACHE_LINE_SIZE];
    lsn_t        lsn;        
    ulint        buf_free;   // buffer 内剩餘空間的起始點的 offset
#ifndef UNIV_HOTBACKUP
    char        pad2[CACHE_LINE_SIZE];
    LogSysMutex    mutex;        
    LogSysMutex    write_mutex;    
    char        pad3[CACHE_LINE_SIZE];
    FlushOrderMutex    log_flush_order_mutex;
#endif /* !UNIV_HOTBACKUP */
    byte*        buf_ptr;    // 隐性的 buffer
    byte*        buf;        // 真正操作的 buffer
    bool        first_in_use;    
    ulint        buf_size;   // buffer大小
    bool        check_flush_or_checkpoint;
    UT_LIST_BASE_NODE_T(log_group_t) log_groups;

#ifndef UNIV_HOTBACKUP
    /** The fields involved in the log buffer flush @{ */
    ulint        buf_next_to_write;
    volatile bool    is_extending;    
    lsn_t        write_lsn;    /*!< last written lsn */
    lsn_t        current_flush_lsn;
    lsn_t        flushed_to_disk_lsn;
    ulint        n_pending_flushes;
    os_event_t    flush_event;    
    ulint        n_log_ios;    
    ulint        n_log_ios_old;    
    time_t        last_printout_time;

    /** Fields involved in checkpoints @{ */
    lsn_t        log_group_capacity; 
    lsn_t        max_modified_age_async;
    lsn_t        max_modified_age_sync;
    lsn_t        max_checkpoint_age_async;
    lsn_t        max_checkpoint_age;
    ib_uint64_t    next_checkpoint_no;
    lsn_t        last_checkpoint_lsn;
    lsn_t        next_checkpoint_lsn;
    mtr_buf_t*    append_on_checkpoint;
    ulint        n_pending_checkpoint_writes;
    rw_lock_t    checkpoint_lock;
#endif /* !UNIV_HOTBACKUP */
    byte*        checkpoint_buf_ptr;
    byte*        checkpoint_buf;    
    /* @} */
};

redo log buffer 本質上隻是一個 byte 數組，但是為了維護這個 buffer 還需要設定很多其他的 meta data，這些 meta data 全部封裝在 log_t 結構體中。

總結

這篇文章主要介紹了 MySQL 裡面最重要的兩個日志，即實體日志 redo log（重做日志）和邏輯日志 binlog（歸檔日志），還講解了有與日志相關的一些問題。

另外還介紹了與 MySQL 日志系統密切相關的兩階段送出（2PC），兩階段送出是解決分布式系統的一緻性問題常用的一個方案，類似的還有 三階段送出（3PC） 和 PAXOS 算法。

sql 存儲 關系型資料庫 mysql 資料庫 binlog日志mysql mysql系統學習redo日志 binlog無法啟動日志mysql mysql日志binlog說明 binlog錯誤日志mysql
上一篇: 11月6日，聊城阿裡雲創學院第五期甯波研學，即将啟動
下一篇: 為什麼阿裡巴巴Java開發手冊中不建議在循環體中使用+進行字元串拼接？為什麼 StringBuilder 比 + 快這麼多？使用 + 拼接字元串使用 StringBuilder 拼接字元串總結

繼續閱讀