MySQL 的一致性日志

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

答案：依靠日志。

因為在執(zhí)行一個操作之前，數(shù)據(jù)庫會首先把這個操作的內(nèi)容寫入到文件系統(tǒng)日志里，然后再進行操作。當宕機或者斷電的時候，即使操作并沒有執(zhí)行完，但是日志在操作前就已經(jīng)寫好了，我們?nèi)匀豢梢愿鶕?jù)日志的內(nèi)容來進行恢復。

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

redo log

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

undo log

和 redo 日志對應，也叫撤消日志，記錄事務開始前數(shù)據(jù)的狀態(tài)。

當一些更改在執(zhí)行一半時發(fā)生意外而無法完成，就可以根據(jù)撤消日志恢復到更改之前的狀態(tài)。

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

binlog

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

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

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

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

//查看binlog文件的內(nèi)容show binlog events;//查看指定binlog文件的內(nèi)容show binlog events in ’MySQL-bin.000001’;//查看正在寫入的binlog文件show master statusG //獲取binlog文件列表show binary logs;XA 規(guī)范是如何定義的

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

事務協(xié)調(diào)者（Transaction Manager）

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

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

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

資源管理器（Resource Manager）

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

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

XA 事務的執(zhí)行流程

XA 事務是兩階段提交的一種實現(xiàn)方式，根據(jù) 2PC 的規(guī)范，XA 將一次事務分割成了兩個階段，即 Prepare 和 Commit 階段。

Prepare 階段

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

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

Commit 階段

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

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

MySQL 如何實現(xiàn) XA 規(guī)范

MySQL 中 XA 事務有兩種情況，內(nèi)部 XA 和外部 XA，其區(qū)別是事務發(fā)生在 MySQL 服務器單機上，還是發(fā)生在多個外部節(jié)點間上。

內(nèi)部 XA

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

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

外部 XA

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

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

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

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

binlog 中的 Xid

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

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

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

binlog 同步過程

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

當有事務提交時：

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

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

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

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

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

以上就是MySQL數(shù)據(jù)庫是如何實現(xiàn)XA規(guī)范的的詳細內(nèi)容，更多關于MySQL數(shù)據(jù)庫XA規(guī)范的資料請關注好吧啦網(wǎng)其它相關文章！