我們需要先了解下redo log、bin log的區別:
- Binlog是server層的日志，主要做mysql功能層面的事情
-
與redo日志的區別:
- redo是innodb獨有的，binlog是所有引擎都可以使用的
-
redo是物理日志，記錄的是在某個數據頁上做了什么修改，binlog是邏輯日志，記錄的是這個語句的原始邏輯
-
redo是循環寫的，空間會用完，binlog是可以追加寫的，不會覆蓋之前的日志信息
binlog：
-
Binlog中會記錄所有的邏輯，並且采用追加寫的方式
-
一般在企業中數據庫會有備份系統，可以定期執行備份，備份的周期可以自己設置
-
恢復數據的過程：– 1、找到最近一次的全量備份數據– 2、從備份的時間點開始，將備份的binlog取出來，重放到要恢復的那個時刻
數據更新的流程：
執行流程：
1、執行器先從引擎中找到數據，如果在內存中直接返回，如果不在內存中，查詢后返回
2、執行器拿到數據之后會先修改數據，然后調用引擎接口重新吸入數據
3、引擎將數據更新到內存，同時寫數據到redo中，此時處於prepare階段，並通知執行器執行完成，隨時可以操作
4、執行器生成這個操作的binlog
5、執行器調用引擎的事務提交接口，引擎把剛剛寫完的redo改成commit狀態，更新完成
redo log為什么需要兩階段提交?
▪ 先寫redo log后寫binlog:假設在redo log寫完，binlog還沒有寫完的時候，MySQL進程
異常重啟。由於我們前面說過的，redo log寫完之后，系統即使崩潰，仍然能夠把數據恢復
回來，所以恢復后這一行c的值是1。但是由於binlog沒寫完就crash了，這時候binlog里面
就沒有記錄這個語句。因此，之后備份日志的時候，存起來的binlog里面就沒有這條語句。
然后你會發現，如果需要用這個binlog來恢復臨時庫的話，由於這個語句的binlog丟失，這
個臨時庫就會少了這一次更新，恢復出來的這一行c的值就是0，與原庫的值不同。
▪ 先寫binlog后寫redo log:如果在binlog寫完之后crash，由於redo log還沒寫，崩潰恢復
以后這個事務無效，所以這一行c的值是0。但是binlog里面已經記錄了“把c從0改成1”這個
日志。所以，在之后用binlog來恢復的時候就多了一個事務出來，恢復出來的這一行c的值
就是1，與原庫的值不同。