免費學習推薦:mysql影片教學
目錄
一、簡介
二、redo log
三. binlog
四. 內部工作流程
MySql學習欄位
1. MySQL基礎架構詳解
2. MySQL索引底層資料結構與演算法
3. MySQL5.7開啟binlog日誌,及資料復原簡單範例
4. MySQL日誌模組
一、介紹
MySQL 有兩大重要的日誌模組:redo log(重做日誌)和 binlog(歸檔日誌)。
redo log是InnoDB儲存引擎層的日誌,binlog是MySQL Server層記錄的日誌, 兩者都是記錄了某些操作的日誌,但兩者記錄的格式不同。
二、redo log
redo log: 又稱(重做日誌)文件,用於記錄事務操作的變化,記錄的是資料修改之後的值,不管交易是否提交都會記錄下來。
在media failure時,redo log檔案就能派上用場,如資料庫掉電,InnoDB儲存引擎會使用redo log恢復到掉電前的時刻,以此來確保資料的完整性。
當有一筆記錄需要更新的時候,InnoDB 引擎就會先把記錄寫到 redo log 裡面,並更新內存,這個時候更新就算完成了。
InnoDB 引擎會在適當的時候,將這個操作記錄更新到磁碟裡面,而這個更新一般是在系統比較空閒的時候完成的,以此來提升更新效率。
這裡牽涉到 ##WAL 即 Write-Ahead Logging #技術,他的關鍵點就是 先寫日誌,再寫磁碟。
InnoDB 的 redo log 是固定大小的,例如可以配置為一組 4 個文件,每個文件的大小是 1GB,那麼總共就可以記錄 4GB 的操作。 redo log會從頭開始寫,寫到結尾又回到開頭循環寫,如下圖。write pos 是目前記錄的位置,一邊寫一邊後移,寫到第3 號文件結束後就回到0 號文件開頭。
check point 是目前要擦除的位置,也是往後推移且循環的,擦除記錄前要把記錄更新到資料檔案。
write pos 和 check point# 之間的是未使用的部分,可以用來記錄新的作業。
如果write pos 追上 check point,表示redo log記錄滿了,這時候不能再執行新的更新,得停下來先擦掉一些記錄,把 check point 推進一下。
有了 redo log,InnoDB 就可以保證即使資料庫發生異常重啟,先前提交的記錄都不會遺失,這個能力稱為crash-safe。
為什麼要使用redo log日誌?
假如我們對資料庫進行DML操作,直接把執行SQL寫入磁碟,當寫入並發較大時,對資料寫入磁碟的壓力會造成一定影響,當我們插入操作是,發現當前非葉子節點一頁資料量不夠時,要進行分頁演算法,效率會比較低;當我使用redo log日誌,先把我們DML操作寫入日誌,透過一個"中轉站",空閒時候再透過check point 寫入磁碟,效率會高很多;
MySQL設定Redo Log
三. binlog
redo log 是InnoDB 引擎特有的日誌,而Server層也有自己的日誌,稱為 binlog(歸檔日誌)。
為什麼會有兩份日誌呢?
因為最開始 MySQL 裡並沒有 InnoDB 引擎。 MySQL 自帶的引擎是 MyISAM,但是 MyISAM 沒有 crash-safe 的能力,binlog 日誌只能用於歸檔。
而InnoDB 是另一個公司以插件形式引入MySQL 的,既然只依賴binlog 是沒有crash-safe 能力的,所以InnoDB 使用另一個日誌系統-也就是redo log 來實作 crash-safe 能力。
這兩種日誌有以下三點不同。
四. 內部工作流程
以一個表格的更新語句為例,來看看執行器和InnoDB 引擎的內部工作流程:
mysql> update T set c=c+1 where ID=2;
如下圖所示,淺色框表示是在InnoDB 內部執行的,深色框表示是在執行器中執行的:
兩階段提交"。
為什麼日誌需要 "兩階段提交"?這裡可以用反證法來解釋。
由於 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,與原始庫的值不同。
可以看到,如果不使用“兩階段提交”,那麼資料庫的狀態就有可能和用它的日誌恢復出來的庫的狀態不一致# 。
相關免費學習推薦:mysql資料庫(影片)
以上是記錄MySQL日誌模組的詳細內容。更多資訊請關注PHP中文網其他相關文章!