MySQL可以恢復到半月內任意一秒的狀態！如何做到的？
得從一個表的一條更新語句說起。
- 創建一個男人表，主鍵id和整型字段age：
- 插倆數據。
![]()
- 將id=2這一行的值加1
![]()
SQL語句基本的執行流程同樣適用於更新語句。
- 執行語句前要先通過連接器連接數據庫
- 表上有更新時，此表有關查詢緩存就會失效，所以這條語句就會把表man上所有緩存置空
- 分析器會通過詞法和語法解析知道這是一條更新語句
- 優化器決定使用id索引
- 執行器負責具體執行，找到這一行，更新
與查詢流程不同的是更新涉及兩個日誌模塊
- redo log（重做日誌）
- binlog（歸檔日誌）
redo log
賒賬或者還賬的話，一般有兩種做法：
- 直接把賬本翻出來，把這次賒的賬加上去或者扣除掉
- 先在粉板上記下這次的賬，等打烊再把賬本翻出來覈算
在生意忙時，掌櫃一定選後者，因爲前者太麻煩：
- 首先，得從一堆記錄找到這個人的賒賬記錄
- 找到後再拿出算盤計算
- 最後再將結果寫回到賬本
還是先在粉板上記一下方便。如果掌櫃沒有粉板，每次記賬都翻賬本，效率是不是低死啦？
MySQL也有這個問題，若每次更新操作都寫進磁盤，然後磁盤也要找到對應記錄，然後再更新，整個過程IO成本、搜索成本都很高。
何解？採用類似酒掌櫃粉板的思路。
粉板和賬本的配合過程，就是MySQL裏的WAL（Write-Ahead Logging）關鍵就是
- 先寫日誌（先寫粉板）
- 再寫磁盤（不忙時寫賬本）
當一條記錄需要更新，InnoDB先把記錄寫到redo log（粉板）裏面，並更新內存，更新就算完成了
InnoDB在適當時，將操作記錄更新到磁盤，而這個更新往往是在系統比較空閒的時候做，這就像打烊以後掌櫃做的事。
如果今天賒賬不多，掌櫃可以打烊後整理。如果某天賒賬多，粉板寫滿，怎麼辦？
放下手中活兒，把粉板一部分賒賬記錄更新到賬本，然後把這些記錄從粉板上擦掉，爲記新賬騰出空間。
類似的InnoDB的redo log固定大小，比如可配置爲一組4個文件，每個文件的大小是1GB，那麼這塊“粉板”總共就可以記錄4GB的操作。
- 從頭開始寫，寫到末尾就又回到開頭循環寫
![]()
write pos是當前記錄位置，一邊寫一邊後移，寫到第3號文件末尾後回到0號文件開頭
checkpoint是當前要擦除位置，往後推移並且循環，擦除記錄前要把記錄更新到數據文件
write pos和checkpoint之間是“粉板”上還空着的部分，用來記錄新操作。如果write pos追上checkpoint，“粉板”滿，不能再執行新的更新，得停下來先擦掉一些記錄，checkpoint推進。
redo log可以保證即使數據庫發生異常重啓，之前提交的記錄都不會丟失，這個能力稱爲crash-safe。
只要賒賬記錄記在了粉板上或寫在了賬本上，之後即使掌櫃忘記了，比如突然停業，恢復生意後依然可以通過賬本和粉板上的數據明確賒賬賬目。
binlog
MySQL Server層，它主要做的是MySQL功能層面的事情
引擎層，負責存儲相關的具體事宜
粉板redo log是InnoDB引擎特有的日誌，而Server層也有自己的日誌，稱爲binlog（歸檔日誌）。
爲什麼需要兩份日誌？
最開始MySQL並無InnoDB，自帶的是MyISAM，沒有crash-safe的能力，binlog只能用於歸檔。
InnoDB是另一個公司以插件形式引入MySQL，只依靠binlog沒有crash-safe，所以InnoDB使用另外一套日誌系統redo log實現crash-safe能力。
日誌不同。
- redo log是InnoDB引擎特有的；binlog是MySQL的Server層實現的，所有引擎都可以使用
- redo log是物理日誌，記錄的是“在某個數據頁上做了什麼修改”；binlog是邏輯日誌，記錄的是這個語句的原始邏輯，比如“給ID=2這一行的c字段加1 ”
- redo log是循環寫的，空間固定會用完；binlog是可以追加寫入的。“追加寫”是指binlog文件寫到一定大小後會切換到下一個，並不會覆蓋以前的日誌。
看執行器和InnoDB引擎在執行這個簡單的update語句時的內部流程。
- 執行器先找引擎取id=2這行。id是主鍵，引擎直接用b+樹搜索。這一行所在數據頁本就在內存，則直接返回給執行器；否則先從磁盤讀入內存，再返回
- 執行器拿到引擎給的行數據，把這個值加1，得到新的一行數據，再調用引擎接口寫入這行新數據
- 引擎將這行新數據更新到內存，同時將更新操作記錄到redo log，此時redo log處prepare態。然後告知執行器執行完成，隨時可以提交事務
- 執行器生成這個操作的binlog，並把binlog寫入磁盤
- 執行器調用引擎的提交事務接口，引擎把剛剛寫入的redo log改成提交（commit）狀態，更新完成
![]()
淺色框表示是在InnoDB內部執行
深色框表示是在執行器執行
最後三步看上去有點“繞”，將redo log的寫入拆成了兩個步驟：prepare和commit，這就是"兩階段提交"。
兩階段提交
爲什麼必須有“兩階段提交”？
爲了讓兩份日誌之間的邏輯一致。
思考怎樣讓數據庫恢復到半個月內任意一秒的狀態？
binlog會記錄所有的邏輯操作，並且採用“追加寫”。如果DBA承諾說半個月內可以恢復，那麼備份系統中一定會保存最近半個月的所有binlog，同時系統會定期做整庫備份。
“定期”取決於系統的重要性，可以是一天一備，也可以是一週一備。
數據恢復過程
當需要恢復到指定秒時，比如某天下午兩點發現中午十二點有次誤刪表，需要找回數據：
首先，找到最近的一次全量備份，如果運氣好，可能就是昨天晚上備份，從這個備份恢復到臨時庫
然後從備份時間點開始，將備份的binlog依次取出來，重放到中午誤刪表之前的那個時刻
這樣你的臨時庫就跟誤刪之前的線上庫一樣了，然後你可以把表數據從臨時庫取出來，按需要恢復到線上庫去。
爲什麼需要“兩階段提交”
由於redo log和binlog是兩個獨立的邏輯，如果不用兩階段提交，要麼就是先寫完redo log再寫binlog，或者反序。
假設當前ID=2的行，字段c的值是0，再假設執行update語句過程中，在寫完第一個日誌後，第二個日誌還沒有寫完期間發生crash？
先寫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，與原庫的值不同。
看到，不使用“兩階段提交”，那麼數據庫的狀態就有可能和用它的日誌恢復出來的庫的狀態不一致。
概率是不是很低，平時也沒有什麼動不動就需要恢復臨時庫的場景呀？不是的，不只是誤操作後需要用這個過程來恢復數據。需要擴容時，需要再多搭建一些備庫來增加系統的讀能力的時候，現在常見的做法也是用全量備份加上應用binlog來實現的，這個“不一致”就會導致你的線上出現主從數據庫不一致的情況。
redo log和binlog都可以用於表示事務的提交狀態，而兩階段提交就是讓這兩個狀態保持邏輯上的一致。
- innodb_flush_log_at_trx_commit設成1，表示每次事務的redo log都直接持久化到磁盤。建議設成1，保證MySQL異常重啓之後數據不丟失
- sync_binlog這個參數設置成1的時候，表示每次事務的binlog都持久化到磁盤。建議設成1，保證MySQL異常重啓之後binlog不丟失