【MySQL實戰45講基礎篇】(task2)日志系統

學習總結

學習 Mysql 里面最重要的兩個日志，即物理日志 redo log 和邏輯日志 binlog。

（1）redo log 用于保證 crash-safe 能力。innodb_flush_log_at_trx_commit 這個參數設置成 1 的時候，表示每次事務的 redo log 都直接持久化到磁盤。建議設置成 1，這樣可以保證 Mysql 異常重啟之后數據不丟失。

（2）sync_binlog 這個參數設置成 1 的時候，表示每次事務的 binlog 都持久化到磁盤。建議設置成 1，這樣可以保證 MySQL 異常重啟之后 binlog 不丟失。

（3）兩個日志之間的三大不同點：

（4）與 MySQL 日志系統密切相關的“兩階段提交”。兩階段提交是跨系統維持數據邏輯一致性時常用的一個方案，即使你不做數據庫內核開發，日常開發中也有可能會用到。

文章目錄

學習總結

一、物理日志 redo log

1.1 記賬栗子

1.2 crash-safe能力

二、邏輯日志 binlog

2.1 redo log和binlog的區別

2.2 update栗子的執行流程

2.3 binlog幾大模式

三、兩階段提交

3.1 數據恢復

3.2 為啥需要兩階段提交

（1）先寫 redo log 后寫 binlog

（2）先寫 binlog 后寫 redo log

四、作業

Reference

本次task學習redo log（重做日志）和 binlog（歸檔日志）。

（1）先從一個update栗子開始，首先創建一個表，這個表有一個主鍵 ID 和一個整型字段 c。如果要將 ID=2 這一行的值加 1，SQL 語句如下：：

mysql> create table T(ID int primary key, c int); mysql> update T set c=c+1 where ID=2;

1

2

（2）帶著問題學習：怎樣讓數據庫恢復到半個月內任意一秒的狀態？

一、物理日志 redo log

1.1 記賬栗子

1.2 crash-safe能力

InnoDB 的 redo log 是固定大小的，比如可以配置為一組 4 個文件，每個文件的大小是 1GB，那么這塊“粉板”總共就可以記錄 4GB 的操作。從頭開始寫，寫到末尾就又回到開頭循環寫（如下圖）。

（1）write pos 是當前記錄的位置，一邊寫一邊后移，寫到第 3 號文件末尾后就回到 0 號文件開頭。

（2）checkpoint 是當前要擦除的位置，也是往后推移并且循環的，擦除記錄前要把記錄更新到數據文件。

有了 redo log，InnoDB 就可以保證即使數據庫發生異常重啟，之前提交的記錄都不會丟失，這個能力稱為 crash-safe。

二、邏輯日志 binlog

Mysql整體分為server層（負責功能層面）和引擎層（負責存儲相關），redo log是InnoDB引擎特有的日志，而server層也有自己的日志——歸檔日志binlog。

一開始mysql沒有InnoDB引擎，其自帶的是MyISAM引擎沒有crash-safe能力，而當時是以插件的形式引入其他公司的InnoDB。InnoDB使用另一套日志系統redo log來實現crash-safe能力。

2.1 redo log和binlog的區別

redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 層實現的，所有引擎都可以使用。

redo log 是物理日志，記錄的是“在某個數據頁上做了什么修改”；binlog 是邏輯日志，記錄的是這個語句的原始邏輯，比如“給 ID=2 這一行的 c 字段加 1 ”。

redo log 是循環寫的，空間固定會用完；binlog（邏輯日志） 是可以追加寫入的?！白芳訉憽笔侵?binlog 文件寫到一定大小后會切換到下一個（生成一個新的文件），并不會覆蓋以前的日志。

2.2 update栗子的執行流程

回到開頭update的例子，看執行流程。

淺色框表示是在 InnoDB 內部執行的，深色框表示是在執行器中執行的。

執行器先找引擎取 ID=2 這一行。ID 是主鍵，引擎直接用樹搜索找到這一行。如果 ID=2 這一行所在的數據頁本來就在內存中，就直接返回給執行器；否則，需要先從磁盤讀入內存，然后再返回。

執行器拿到引擎給的行數據，把這個值加上 1，比如原來是 N，現在就是 N+1，得到新的一行數據，再調用引擎接口寫入這行新數據。

引擎將這行新數據更新到內存中，同時將這個更新操作記錄到 redo log（物理日志） 里面，此時 redo log 處于 prepare 狀態。然后告知執行器執行完成了，隨時可以提交事務。

執行器生成這個操作的 binlog（邏輯日志），并把 binlog 寫入磁盤。

執行器調用引擎的提交事務接口，引擎把剛剛寫入的 redo log 改成提交（commit）狀態，更新完成。

2.3 binlog幾大模式

三、兩階段提交

剛才上圖的最后三步看上去有點“繞”，將 redo log 的寫入拆成了兩個步驟：prepare 和 commit，這就是"兩階段提交"。

3.1 數據恢復

開頭說的讓數據庫恢復到半個月內任意一秒的狀態的問題：

binlog（MySQL 的 Server 層實現的，所有引擎都可以使用）會記錄所有的邏輯操作，用“追加寫”方式，如果DBA說半個月可以恢復，則說明備份系統中保存了最近半個月所有的binlog（系統會定期備份）。

ex：想要找到到最近某天誤刪的數據，可以把備份的binlog依次取出，這時臨時庫就和誤刪前的數據庫一樣了，可以取出所要的數據。

3.2 為啥需要兩階段提交

為啥日志需要兩階段提交，我們使用反證法。

由于 redo log 和 binlog 是兩個獨立的邏輯，

如果不用兩階段提交，要么就是先寫完 redo log 再寫 binlog，或者采用反過來的順序

?？纯催@兩種方式會有什么問題。

仍然用前面的 update 語句來做例子。假設當前 ID=2 的行，字段 c 的值是 0，再假設執行 update 語句過程中在寫完第一個日志后，第二個日志還沒有寫完期間發生了 crash，會出現什么情況呢？

（1）先寫 redo log 后寫 binlog

假設在 redo log 寫完，binlog 還沒有寫完的時候，MySQL 進程異常重啟。由于我們前面說過的，redo log 寫完之后，系統即使崩潰，仍然能夠把數據恢復回來，所以恢復后這一行 c 的值是 1。但是由于 binlog 沒寫完就 crash 了，這時候 binlog 里面就沒有記錄這個語句。因此，之后備份日志的時候，存起來的 binlog 里面就沒有這條語句。然后你會發現，如果需要用這個 binlog 來恢復臨時庫的話，由于這個語句的 binlog 丟失，這個臨時庫就會少了這一次更新，恢復出來的這一行 c 的值就是 0，與原庫的值不同。

（2）先寫 binlog 后寫 redo log

如果在 binlog 寫完之后 crash，由于 redo log 還沒寫，崩潰恢復以后這個事務無效，所以這一行 c 的值是 0。但是 binlog 里面已經記錄了“把 c 從 0 改成 1”這個日志。所以，在之后用 binlog 來恢復的時候就多了一個事務出來，恢復出來的這一行 c 的值就是 1，與原庫的值不同。

不只是誤操作后需要用這個過程來恢復數據。當你需要擴容的時候，也就是需要再多搭建一些備庫來增加系統的讀能力的時候，現在常見的做法也是用全量備份加上應用 binlog 來實現的，這個“不一致”就會導致你的線上出現主從數據庫不一致的情況。

小結：redo log 和 binlog 都可以用于表示事務的提交狀態，而兩階段提交就是讓這兩個狀態保持邏輯上的一致。

四、作業

前面說到定期全量備份的周期“取決于系統重要性，有的是一天一備，有的是一周一備”。那么在什么場景下，一天一備會比一周一備更有優勢呢？或者說，它影響了這個數據庫系統的哪個指標？

【答】首先，是恢復數據丟失的時間，既然需要恢復，肯定是數據丟失了。如果一天一備份的話，只要找到這天的全備，加入這天某段時間的binlog來恢復，如果一周一備份，假設是周一，而你要恢復的數據是周日某個時間點，那就，需要全備+周一到周日某個時間點的全部binlog用來恢復，時間相比前者需要增加很多；看業務能忍受的程度

其次，是數據庫丟失，如果一周一備份的話，需要確保整個一周的binlog都完好無損，否則將無法恢復；而一天一備，只要保證這天的binlog都完好無損；當然這個可以通過校驗，或者冗余等技術來實現，相比之下，上面那點更重要

Reference

（1）《MySQL實戰45講》

（2）https://www.cnblogs.com/luoahong/p/10385466.html

MySQL 數據庫

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。