mysql的XA與innodb_support_xa

Mysql支援兩種XA：

 

外部XA

應用程式是協調者（coordinator），引數事務的伺服器節點就是資源管理器（resource manager），目前存在兩個問題：

問題1：當引數分散式事務的協調者退出後，即使參與分散式事務的節點都已經PREPARE成功。從理論上說，這時這些分散式事務是懸掛事務，協調者恢復後可以進行最後的第二階段提交。但是這在MySQL資料庫中是不可行的，協調者退出，整個XA事務都回滾；

--此問題不會導致資料丟失或不一致；

 

問題2：參與分散式事務的節點已經PREPARE成功，但是發生資料庫當機導致重啟。這時重啟之後可以發現懸掛的XA事務，可以進行提交。但是提交後，不寫入二進位制日誌檔案，這時會導致主從資料不一致。

那就寫二進位制日誌嘛，問題不就解決了？是的，貌似可以。但是這對replication有很大的影響。因為分散式事務的PREPARE是在事務提交前就寫了，但是二進位制日誌實在事務提交時才寫的。這樣會導致replication由於分散式事務，而導致可能被長時間等待的情況。

網易的MySQL分支版本InnoSQL中，已經對該問題進行了修復。修復的方案很簡單，PREPARE成功的事務寫日誌，但並不是寫在二進位制日誌中，而是寫在每個對應分散式事務的單獨檔案中。

 

 

內部XA

現在mysql內部一個處理流程大概是這樣：

1. prepare ，然後將redo log持久化到磁碟

2. 如果前面prepare成功，那麼再繼續將事務日誌持久化到binlog

3. 如果前面成功，那麼在redo log裡面寫上一個commit記錄

那麼假如在進行著三步時又任何一步失敗，crash recovery是怎麼進行的呢?

此時會先從redo log將最近一個檢查點開始的事務讀出來，然後參考binlog裡面的事務進行恢復。

如果是在1 crash，那麼自然整個事務都回滾；

如果是在2 crash，那麼也會整個事務回滾；

如果是在3 crash（僅僅是commit記錄沒寫成功），那麼沒有關係因為2中已經記錄了此次事務的binlog，所以將這個進行commit。所以總結起來就是redo log裡凡是prepare成功，但commit失敗的事務都會先去binlog查詢判斷其是否存在（透過XID進行判斷，是不是經常在binlog裡面看到Xid=xxxx？這就是xa事務id），如果有則將這個事務commit，否則rollback。

http://www.csdn123.com/html/blogs/20130620/24553.htm

 

Mysql為TM，儲存引擎為RM；

Internal XA要求儲存引擎在table handler級別支援2階段提交，5.6只支援innodb；

binlog本身也會prepare/commit，但是binlog的prepare階段不做任何事情（意味著不可能失敗），程式碼中可以看見binlog_prepare函式是空的，寫入binlog的過程是在commit階段做的（在其他事務儲存引擎commit之前），binlog具有“原子”性：每個事務產生的binlog是連續、完整的寫入到binlog檔案中，事務之間不會交叉寫（與InnoDB的redo log不同），因此在crash recovery階段，如果redo log中未提交的事務能夠在binlog中發現，說明其已經prepare成功，可以直接提交，而如果redo中未提交事務不在binlog中，直接回滾事務，這樣能夠保證binlog和儲存引擎資料的一致。

 

 

 

innodb_support_xa

預設為true，如果關閉則binlog記錄事務的順序可能與實際不符，造成slave不一致

If you turn it off, transactions can be written to the binary log in a different order from the one in which the live database is committing them. This can produce different data when the binary log is replayed in disaster recovery or on a replication slave. Do not turn it off on a replication master server unless you have an unusual setup where only one thread is able to change data.

 

 

http://dev.mysql.com/doc/refman/5.6/en/xa-restrictions.html

If an XA transaction has reached the PREPARED state and the MySQL server is killed (for example, with kill -9 on Unix) or shuts down abnormally, the transaction can be continued after the server restarts. However, if the client reconnects and commits the transaction, the transaction will be absent from the binary log even though it has been committed. This means the data and the binary log have gone out of synchrony. An implication is that XA cannot be used safely together with replication

 

 

 

http://insidemysql.blog.163.com/blog/static/2028340422013102662420500/