redo log(重做日誌)

Innodb引擎持有

WAL技術

Write-Ahead Logging，先寫日誌再寫磁碟。當一條記錄需要更新時，InnoDB引擎先把記錄寫到redo log裡面，並更新記憶體，這次更新就算完成了。InnoDB引擎會在適當時候將這個操作記錄更新到磁碟。

執行過程

write pos：當前記錄位置，一遍寫一遍後移。
check point：當前要擦除的位置（更新到磁碟），往後推移。
write pos和check point之間可以用來記錄新的操作；當write pos追上check point時，此時不能再執行新的更新；需要等待check point擦除一部分記錄再執行更新。
基於redo log，InnoDB可以保證資料庫發生異常重啟，之前提交的記錄都不會丟失，即crash-safe。

binlog日誌（server層日誌）

redo log與binlog日誌不同點

Update語句執行過程

mysql> update T set c=c+1 where ID=2;

深色：執行器中執行；淺色：InnoDB中執行
此處將redo log的寫入拆分為兩個步驟：prepare和commit。——兩階段提交
兩階段提交可以保證redo log和binlog的狀態保持邏輯一致。（事務性）——可以保證資料恢復

相關設定

• innodb_flush_log_at_trx_commit：設定為1，每次事務的redo log都直接持久化到磁碟；保證mysql異常重啟資料不丟失；
• sync_binlog：設定為1，每次事務的binlog都持久化到磁碟；保證mysql異常重啟後binlog不丟失。

MySQL如何判斷binlog完整

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

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

5.6.2版本以後，引入了binlog-checksum引數，用來驗證binlog內容的正確性。

redolog和binlog如何關聯

他們有一個共同的資料欄位XID。崩潰恢復的時候，會順序掃描redo log：

• 如果碰到既有prepare，又有commit的redo log，就直接提交；
• 如果碰到只有prepare，沒有commit的redo log，就拿著XID去binlog找對應的事務。