文章目錄
一：什麼是redolog和binglog？
| redo log | Binglog | |
|---|---|---|
| 日誌類型 | 物理日誌 物理日誌即數據頁中的真實二級制數據，恢復速度快 |
邏輯日誌 即sql語句，因需要逐條執行，恢復速度慢 |
| 存儲格式 | innodb存儲引擎數據的單位是頁，redo log也是基於頁進行存儲，一個默認16K大小的頁中存了很多512Byte的log block，log block的存儲格式如下 [log block header 12Byte，log block body 492 Bytes，log block tailer 8 Bytes] |
statement：SQL語句的形式 row：記錄相關行的每一列的值（官方推薦） |
| 用途 | 重做數據頁 | 數據複製 |
| 所處層級 | innodb存儲引擎中 | 存儲引擎的上層，因此不管用什麼存儲引擎，都可以開啓binlog |
二：redolog和binlog可以相互替代或者只保留其一嗎？
1. 可以使用binlog替代redolog進行數據恢復嗎？
不可以
innodb利用wal技術進行數據恢復，write ahead logging技術依賴於物理日誌進行數據恢復，binlog不是物理日誌是邏輯日誌，因此無法使用
2. 可以只使用redolog而不使用binlog嗎？
不可以
redolog是循環寫，寫到末尾要回到開頭繼續寫，這樣的日誌無法保留歷史記錄，無法進行數據複製。
三：爲什麼redolog和binlog要進行二階段提交？
首先區分一個概念，commit步驟是屬於begin…commit語句中的一個步驟，且是最後一個步驟，兩個commit是包含的關係。
如果redo log持久化並進行了提交，而binlog未持久化數據庫就crash了，則從庫從binlog拉取數據會少於主庫，造成不一致。因此需要內部事務來保證兩種日誌的一致性。
四：二階段提交步驟
prepare：redolog寫入log buffer，並fsync持久化到磁盤，在redolog事務中記錄2PC的XID，在redolog事務打上prepare標識
commit：binlog寫入log buffer，並fsync持久化到磁盤，在binlog事務中記錄2PC的XID，同時在redolog事務打上commit標識
其中，prepare和commit階段所提到的“事務”，都是指內部XA事務，即2PC
五、redolog和binlog二階段提交與redolog和binlog的順序提交是否真的有區別？
如果redolog和binlog順序提交，則具體步驟會如下：
-
redolog刷入cache並fsync刷盤，並打上commit標識
-
binlog刷入cache並fsync刷盤
類比begin…commit和begin…rollback，commit和rollback這兩個操作是隻能二選一，且一旦commit則不能再rollback。同樣，redolog中的事務一旦打上commit標識，是無法回退的，否則有可能覆蓋其他事務的更新（例如A事務對某一行進行了插入並打上commit標識，而B事務緊接着對該行進行了修改，最後A事務突然回滾B事務，則B事務的操作被強制覆蓋，這是不妥的）。如果redolog進行了commit，而此時數據庫crash導致binlog刷盤失敗，redolog無法回滾，會造成redolog和binlog不一致。
但是通過事務可以同時提交redolog和binlog，兩者落盤之後都會記錄2PC事務的XID（redolog和binlog中事務落盤的標識），若中途數據庫crash，通過XID關聯兩者並在恢復時決定commit和rollback與否，詳細步驟見下一段“恢復步驟”。
六：恢復步驟？
redolog中的事務如果經歷了二階段提交中的prepare階段，則會打上prepare標識，如果經歷commit階段，則會打上commit標識（此時redolog和binlog均已落盤）。
Step1. 按順序掃描redolog，如果redolog中的事務既有prepare標識，又有commit標識，就直接提交（複製redolog disk中的數據頁到磁盤數據頁）
Step2 .如果redolog事務只有prepare標識，沒有commit標識，則說明當前事務在commit階段crash了，binlog中當前事務是否完整未可知，此時拿着redolog中當前事務的XID（redolog和binlog中事務落盤的標識），去查看binlog中是否存在此XID
a. 如果binlog中有當前事務的XID，則提交事務（複製redolog disk中的數據頁到磁盤數據頁）
b. 如果binlog中沒有當前事務的XID，則回滾事務（使用undolog來刪除redolog中的對應事務）
可以將mysql redolog和binlog二階段提交和廣義上的二階段提交進行對比，廣義上的二階段提交，若某個參與者超時未收到協調者的ack通知，則會進行回滾，回滾邏輯需要開發者在各個參與者中進行記錄。mysql二階段提交是通過xid進行恢復。
參考：
http://blog.itpub.net/28218939/viewspace-1975809/
https://www.cnblogs.com/f-ck-need-u/p/9010872.html#auto_id_16
https://www.cnblogs.com/f-ck-need-u/p/9001061.html#auto_id_14
https://www.infoq.cn/article/M6g1yjZqK6HiTIl_9bex
https://www.cnblogs.com/wupeixuan/p/11734501.html
https://segmentfault.com/a/1190000014810628
https://www.cnblogs.com/stevenczp/p/6265686.html
https://www.cnblogs.com/clouddbdever/p/5627409.html
https://juejin.im/post/5e5c6620f265da5741120978#heading-4