看完了前2天內容就為了今天的主題二階段提交，相信在下面你就能更明白整個流程的走向。

二階段提交(Two-phase Commit)

ps.2個參數sync_binlog/innodb_flush_log_at_trx_commit 都為預設1的狀況下

• 作用: 保證(Server層)binlog與(引擎層)redo log的數據一致性。

• 二階段提交在執行事務提交的過程把redo log寫入分成2步驟

1. prepare階段: 寫redolog標示為prepare狀態。
2. commit 階段: 寫binlog後將redolog標示更新成commit狀態，事務提交更新成功。

詳細流程看圖～

Q: 為何要保證2個日誌的一致性？

首先我們知道在主從架構下從庫的資料複製是靠binlog完成的，而redo log跟資料庫數據恢復有關，undo log跟事務的回滾操作有關。

那當在圖中(1),(2),(3)不同階段發生資料庫crash！，事務恢復的過程是如何進行的 ~

1. redo log prepare階段

   • redo log prepare -[NO]

   恢復時: prepare階段就crash了，binlog都沒寫入和提交，不用懷疑rollback事務～

2. 寫binlog 階段異常 -> (rollback事務)

   • redo log prepare -[YES]
   • binlog -[NO]

   恢復時: 在2個日誌邏輯不一樣的狀況下，因為binlog寫入階段異常導致紀錄缺少，當從庫透過binlog更新資料時就會少了這次更新的內容，造成主從數據不一致，rollback事務。

3. 在最後redo log 更新狀態commit階段

   • redo log prepare -[YES]
   • binlog -[YES]
   • redo log commit -[NO]

注意上圖中可以看到redo log在prepare階段 & 寫入binlog 都有紀錄Xid的動作！ 可以說是用來判斷2個日誌的是否達成一致。

恢復時: 會檢查redo log中prepare狀態的事務是否與對應的事務binlog Xid一致(白話文:2邊事務紀錄的xid存在且一致就OK啦～)。沒有就rollback事務，有就commit事務。

• Xid紀錄在哪兒？(擷取binlog內容:一個事務的提交紀錄)
  

總結一下:

在崩潰恢復中，檢查的就是2個日誌內容是否狀態一致，而透過二階段提交機制確保2個日誌的一致性，能在資料庫crash時透過redo log將數據庫內容恢復到crash之前狀態，且透過binlog複製的主從關係在數據一致性上也沒有問題～

本來只想說單純二階段提交就2個日誌的一致性恢復應該寫蠻快的ＸＤ，但看到最後不對喔！太表面根本看不懂整個流程到底怎麼跑..然後就越看越多嗯嗯這主題很棒～
其實學系統真的是常常會有知道這個流程怎麼跑但實際在幹嘛真的不清楚的狀況，真的去理解才發現整個內容一堆細節，看下去就是一大篇

下一篇來介紹個語法～透過應用學習更能知道如何在環境上使用SQL