儲引擎實現事務的通用方式是基於 redo log 和 undo log。
簡單來說，redo log 記錄事務修改後的資料, undo log 記錄事務前的原始資料。
所以當乙個事務執行時實際發生過程簡化描述如下：
先記錄 undo/redo log，確保日誌刷到磁碟上持久儲存。
更新資料記錄，快取操作並非同步刷盤。
提交事務，在 redo log 中寫入 commit 記錄。
在 mysql 執行事務過程中如果因故障中斷，可以通過 redo log 來重做事務或通過 undo log 來回滾，確保了資料的一致性。
這些都是由事務性儲存引擎來完成的，但 binlog 不在事務儲存引擎範圍內，而是由 mysql server 來記錄的。
那麼就必須保證 binlog 資料和 redo log 之間的一致性，所以開啟了 binlog 後實際的事務執行就多了一步，如下：
先記錄 undo/redo log，確保日誌刷到磁碟上持久儲存。
更新資料記錄，快取操作並非同步刷盤。
將事務日誌持久化到 binlog。
提交事務，在 redo log 中寫入提交記錄。
這樣的話，只要 binlog 沒寫成功，整個事務是需要回滾的，而 binlog 寫成功後即使 mysql crash 了都可以恢復事務並完成提交。
要做到這點，就需要把 binlog 和事務關聯起來，而只***了 binlog 和事務資料的一致性，才能保證主從資料的一致性。
所以 binlog 的寫入過程不得不嵌入到純粹的事務儲存引擎執行過程中，並以內部分布式事務（xa 事務）的方式完成兩階段提交。
MySQL分布式事務
mysql5.0.3開始支援分布式事務，只支援innodb引擎。1.分布式事務原理 使用分布式事務的應用程式涉及乙個或多個資源管理器和乙個事務管理器。資源管理器 rm 用於提供通向事務資源的途徑，資料庫伺服器是一種資源管理器。該管理器必須可以提交或回滾由rm管理的事務。事務管理器 tm 用於協調作為...
MYSQL分布式事務
在開發中，為了降低單點壓力，通常會根據業務情況進行分表分庫，將表分布在不同的庫中 庫可能分布在不同的機器上 在這種場景下，事務的提交會變得相對複雜，因為多個節點 庫 的存在，可能存在部分節點提交失敗的情況，即事務的acid特性需要在各個不同的資料庫例項中保證。比如更新db1庫的a表時，必須同步更新d...
Mysql分布式事務
關於mysql分布式事務介紹，可參考 分為兩個階段 準備和執行階段。有兩個角色 事務的管理者 tm 和事務執行者 rm,mysql server xa start 事務啟動標識，使事務處於active狀態 xa end 事務結束標識，使事務處於idle狀態 當事務處於idle狀態，可 xa prep...