重做日志-redolog

是什么

innoDB存儲引擎層面的日志，它的作用是當 數據更新過程中數據庫發生異常導致提交的記錄丟失

為什么

mysql的基本存儲結構是頁（記錄都在頁里面），所以更新語句時，mysql需要先把要更新的語句找到，加載進內存(buffer pool)，再修改對應的記錄，再寫會磁盤

此時就會面臨問題：

1、如果內存中的數據更新了，但是未落入磁盤，mysql掛了怎么辦？

2、每個請求都需要將數據立馬落入磁盤，速度會很慢，mysql可能會頂不住

因此 Innodb引入了redolog

怎么做，實現原理

?

redolog也是需要寫入磁盤的，但它是順序寫入的，順序io比隨機io快很多

目的：當我們修改了數據，寫完內存了，可能還未落入磁盤，數據庫掛掉了，此時可以根據redo log來恢復數據。redo log是順序io，所以寫入速度很快，記錄的是物理變化(xx頁做了xx修改)，文件體積小，所以恢復速度也快
?

• 內容：記錄的是物理數據頁面的修改信息（xx頁做了xx修改），其redo log是順序寫入redo log fail的物理文件中去的
• 介紹一下：redolog又叫重做日志，是存儲引擎層面的日志(innoDb特有的日志)，用于記錄事務操作的變化，記錄的是數據修改之后的值，不管事務是否提交都會記錄下來
• 日志大小是固定的，即寫滿了之后會從頭開始循環寫
• Innodb_log_file_size=100M(指定大小)；Innodb_log_files_in_group=5(指定個數)
  ?

歸檔日志-binlog

binlog（歸檔日志）：是mysql server層面的日志，屬于邏輯日志，是以二進制形式記錄的，記錄的是這個語句的原始邏輯(每條變更的sql語句)，追加寫的方式，即一份日志文件寫到一定大小的時候會更換下一個文件，不會覆蓋。

• 用于復制，在主從復制中，從庫利用主庫上的binlog進行傳播，實現主從同步
• 用于數據庫基于時間點的還原

回滾日志-undolog

undo log：在數據的修改過程中，會記錄一條與當前操作相反的邏輯到undo log中，如果因為某些原因導致事務異常失敗了，可以借助undo log進行回滾，保證事務的完整性

• 提供了回滾的作用，保證事務的原子性
• mvcc的實現

?

redolog 和bin log的區別

	bin log	redo log
實現層面	mysql server層實現的	innoDB存儲引擎層面的
記錄內容	記錄的是邏輯日志（sql語句）	記錄的是物理日志（xx頁做了xx修改）
寫入方式	追加寫入，一個文件寫完可以換一個文件接著寫	循環寫，空間大小固定，會覆蓋
作用	用于主從復制，恢復數據	持久化
提交實際	事務提交時記錄	事務開始時記錄每次的變更信息

redolog是如何保證crash-safe的？

crash-safe是通過redo log的write ops和checkpoint機制來保證的

WAL（write ahead log）日志先行技術：先寫日志，再寫磁盤。對于數據更新操作，先寫入redo log

redo log有兩個關鍵的指針：write ops和checkpoint。write ops是當前記錄的位置，一邊寫一邊后移，無法移動的時候就回到開頭。checkpoint是當前要擦除的位置，也是往后推移并且循環的，擦除記錄前要把數據更新到數據文件。write ops和checkpoint之間還空著的地方，可以用來記錄新的操作，如果write ops追上了checkpoint，此時不能進行新的更新操作，需要停下來先擦除一部分內容
?

redolog 能保證crash-safe，還需要bin log嗎？

看場景

• 主從模式下，binlog是需要的，因為從庫同步主庫的數據依賴于bin log
• 單機模式下，如果不考慮基于某個時間點數據的還原，可以不需要bin log。但是萬一需要恢復某個時間點的數據，是做不到的，所以建議一直開啟bin log

簡言之，red log只有innodb有，別的存儲引擎沒有。redo log是循環寫的，不持久保存，所以還是需要binlog。

?

?

?

?