MySQL 的一致性日志

如果 MySQL 數據庫斷電了，未提交的事務怎么辦？

答案：依靠日志。

因為在執行一個操作之前，數據庫會首先把這個操作的內容寫入到文件系統日志里，然后再進行操作。當宕機或者斷電的時候，即使操作并沒有執行完，但是日志在操作前就已經寫好了，我們仍然可以根據日志的內容來進行恢復。

MySQL InnoDB 引擎中和一致性相關的有重做日志（redo log）、回滾日志（undo log）和二進制日志（binlog）。

redo log

每當有操作執行前，在數據真正更改前會先把相關操作寫入 redo 日志。這樣當發生斷電等意外導致后續任務無法完成時，待系統恢復后就可以繼續完成這些更改。

undo log

和 redo 日志對應，也叫撤消日志，記錄事務開始前數據的狀態。

當一些更改在執行一半時發生意外而無法完成，就可以根據撤消日志恢復到更改之前的狀態。

舉個例子，事務 T1 更新數據 X，對 X 執行 Update 操作，從 10 更新到 20，對應的 Redo 日志為 T1, X, 20>，Undo 日志為 T1, X, 10>。

binlog

是 MySQL sever 層維護的一種二進制日志，MySQL 最重要的日志之一，它記錄了所有的 DDL 和 DML 語句，除了數據查詢語句 select、show 等，還包含語句所執行的消耗時間。

binlog 與 InnoDB 引擎中的 redo/undo log 不同，主要目的是復制和恢復，用來記錄對 MySQL 數據更新或潛在發生更新的 SQL 語句，并以事務日志的形式保存在磁盤中。

binlog 主要應用在 MySQL 的主從復制過程中，MySQL 集群在 Master 端開啟 binlog，Master 把它的二進制日志傳遞給 slaves 節點，再從節點回放來達到 master-slave 數據一致的目的。

你可以連接到 MySQL 服務器，使用下面的命令查看真實的 binlog 數據：

//查看binlog文件的內容
show binlog events;

//查看指定binlog文件的內容
show binlog events in 'MySQL-bin.000001';

//查看正在寫入的binlog文件
show master status\G
 
//獲取binlog文件列表
show binary logs;

XA 規范是如何定義的

XA 是由 X/Open 組織提出的分布式事務規范，XA 規范主要定義了事務協調者（Transaction Manager）和資源管理器（Resource Manager）之間的接口。

事務協調者（Transaction Manager）

因為 XA 事務是基于兩階段提交協議的，所以需要有一個協調者，來保證所有的事務參與者都完成了準備工作，也就是 2PC 的第一階段。

如果事務協調者收到所有參與者都準備好的消息，就會通知所有的事務都可以提交，也就是 2PC 的第二階段。

之所以需要引入事務協調者，是因為在分布式系統中，兩臺機器理論上無法達到一致的狀態，需要引入一個單點進行協調。

資源管理器（Resource Manager）

負責控制和管理實際資源，比如數據庫或 JMS 隊列。

目前，主流數據庫都提供了對 XA 的支持，在 JMS 規范中，即 Java 消息服務（Java Message Service）中，也基于 XA 定義了對事務的支持。

XA 事務的執行流程

XA 事務是兩階段提交的一種實現方式，根據 2PC 的規范，XA 將一次事務分割成了兩個階段，即 Prepare 和 Commit 階段。

Prepare 階段

TM 向所有 RM 發送 prepare 指令，RM 接受到指令后，執行數據修改和日志記錄等操作，然后返回可以提交或者不提交的消息給 TM。

如果事務協調者 TM 收到所有參與者都準備好的消息，會通知所有的事務提交，然后進入第二階段。

Commit 階段

TM 接受到所有 RM 的 prepare 結果，如果有 RM 返回是不可提交或者超時，那么向所有 RM 發送 Rollback 命令。

如果所有 RM 都返回可以提交，那么向所有 RM 發送 Commit 命令，完成一次事務操作。

MySQL 如何實現 XA 規范

MySQL 中 XA 事務有兩種情況，內部 XA 和外部 XA，其區別是事務發生在 MySQL 服務器單機上，還是發生在多個外部節點間上。

內部 XA

在 MySQL 的 InnoDB 存儲引擎中，開啟 binlog 的情況下，MySQL 會同時維護 binlog 日志與 InnoDB 的 redo log，為了保證這兩個日志的一致性，MySQL 使用了 XA 事務，由于是在 MySQL 單機上工作，所以被稱為內部 XA。

內部 XA 事務由 binlog 作為協調者，在事務提交時，則需要將提交信息寫入二進制日志，也就是說，binlog 的參與者是 MySQL 本身。

外部 XA

外部 XA 就是典型的分布式事務，MySQL 支持 XA START/END/PREPARE/Commit 這些 SQL 語句，通過使用這些命令，可以完成分布式事務。

你也可以查看 MySQL 官方文檔，了解更多的 XA 命令。

MySQL 外部 XA 主要應用在數據庫代理層，實現對 MySQL 數據庫的分布式事務支持，例如開源的數據庫中間層，比如淘寶的 TDDL、阿里巴巴 B2B 的 Cobar 等。

外部 XA 一般是針對跨多 MySQL 實例的分布式事務，需要應用層作為協調者，比如我們在寫業務代碼，在代碼中決定提交還是回滾，并且在崩潰時進行恢復。

binlog 中的 Xid

當事務提交時，在 binlog 依賴的內部 XA 中，額外添加了 Xid 結構，binlog 有多種數據類型：

1. statement 格式，記錄為基本語句，包含 Commit
2. row 格式，記錄為基于行
3. mixed 格式，日志記錄使用混合格式

不論是 statement 還是 row 格式，binlog 都會添加一個 XID_EVENT 作為事務的結束，該事件記錄了事務的 ID 也就是 Xid，在 MySQL 進行崩潰恢復時根據 binlog 中提交的情況來決定如何恢復。

binlog 同步過程

下面來看看 binlog 下的事務提交過程，整體過程是先寫 redo log，再寫 binlog，并以 binlog 寫成功為事務提交成功的標志。

當有事務提交時：

• InnoDB 進入 Prepare 階段，并且 write/sync redo log，寫 redo log，將事務的 xid 寫入到 redo 日志中，binlog 不作任何操作
• 進行 write/sync binlog，寫 binlog 日志，也會把 xid 寫入到 binlog
• 調用 InnoDB 引擎的 commit 完成事務的提交，將 commit 信息寫入到 redo 日志中

如果是在第一步和第二步失敗，則整個事務回滾

如果是在第三步失敗，則 MySQL 在重啟后會檢查 xid 是否已經提交，若沒有提交，也就是事務需要重新執行，就會在存儲引擎中再執行一次提交操作，保障 redo log 和 binlog 數據的一致性，防止數據丟失。

實際執行還牽扯到操作系統緩存 buffer 何時同步到文件系統中，所以 MySQL 支持用戶自定義在 commit 時如何將 log buffer 中的日志刷到 log file 中，通過變量 innodb_flush_log_at_trx_Commit 的值來決定。

在 log buffer 中的內容稱為臟日志，感興趣的話可以查詢資料了解下。

以上就是MySQL數據庫是如何實現XA規范的的詳細內容，更多關于MySQL數據庫XA規范的資料請關注腳本之家其它相關文章！