Mysql 百問系列：InnoDB事務的二階段提交

問題：

1. 什麼是二階段提交
2. 爲何須要二階段提交
3. 二階段提交流程

什麼是二階段提交？

### 假設原來id 爲10 的記錄age 爲5
begin;
update student set age = 10 where id = 10;
commit;
複製代碼

通常狀況下，事務提交涉及redo log 和 binlog。
當commit 命令執行時，

• 先進入commit prepare 階段，這個階段事務中新生成的redo log 會被刷到磁盤，並將回滾段置爲prepared狀態。
• commit階段：innodb釋放鎖，釋放回滾段，設置redo log提交狀態，binlog持久化到磁盤，而後存儲引擎層提交。

爲何須要二階段提交？

因爲存在redo log 和 binlog ，而他們兩是相互獨立的。而事務提交必須確保二者同時有效。否則會出現不一致的情形。
假如： redo log 有效，binlog 無對應記錄
在上述例子中若是服務器從事務中回覆，因爲redo log 有效因此id爲10的記錄age仍然會是10，可是因爲binlog日誌沒有記錄，因此若是經過binlog 作主從，或者主備那麼就會致使主從，主備不一致。
假如： redo log 失效，而binlog 有對應記錄，
上述例子中，服務器中對應的id爲10的日誌age就會是修改前的5，而binlog中的日誌會被傳到其餘從服務器，也會致使主從，主備不一致。

二階段提交流程

時間點1
prepare 階段
時間點2
commit 階段
時間點3

時間點1出現問題

這個時候redo log 和 binlog都在內存中，因此本次事務的相關操做都會消失，相對於事務回滾了，不影響數據的一致性。

時間點2出現問題

這個時候redo log已經到磁盤了。binlog沒有刷到磁盤因此會消失。服務器從故障中恢復時，讀取磁盤中的redo log ，可是因爲對應的redo log項仍是prepare狀態，就要判斷binlog 是否完整，若是binlog完整則提交事務，若是binlog不完整則回滾事務。

時間點3出現問題。

這個時候redo log 和 binlog都已經存磁盤，服務器從redo log恢復就行了。

binlog怎麼判斷完整性：

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

redolog 和binlog怎麼聯繫起來：

它們有一個共同的數據字段，叫 XID。
崩潰恢復的時候，會按順序掃描 redo log：若是碰到既有 prepare、又有 commit 的 redo log，就直接提交；若是碰到只有 parepare、而沒有 commit 的 redo log，就拿着 XID 去 binlog 找對應的事務。