從一個線上問題分析binlog與內部XA事務提交步驟

2024-09-07 22:13:04

字體：大中小

來源：轉載

供稿：網友

從一個線上問題分析binlog與內部XA事務提交步驟：

　　1. 問題
　　業務上新增一條訂單記錄，用戶接收到BinLake拉取的MySQL從庫數據消息后，馬上根據消息內的訂單號去查詢同一個MySQL從庫，發現有些時候無法查到該條數據，等待大約500ms～1000ms后再去查詢數據庫，可以查詢到該條數據。
　　注: BinLake為京東商城數據庫技術部自研的一套訂閱和消費MySQL數據庫binlog的組件，本例所描述的問題是業務方希望根據訂閱的binlog來獲取實時訂單等業務消息。
　　2. Binlog與內部XA
　　2.1. XA的概念
　　XA(分布式事務)規范主要定義了(全局)事務管理器(TM: Transaction Manager)和(局部)資源管理器(RM: Resource Manager)之間的接口。XA為了實現分布式事務，將事務的提交分成了兩個階段：也就是2PC (tow phase commit)，XA協議就是通過將事務的提交分為兩個階段來實現分布式事務。
　　兩階段
　　1）prepare 階段
　　事務管理器向所有涉及到的數據庫服務器發出prepare"準備提交"請求，數據庫收到請求后執行數據修改和日志記錄等處理，處理完成后只是把事務的狀態改成"可以提交",然后把結果返回給事務管理器。即：為prepare階段，TM向RM發出prepare指令，RM進行操作，然后返回成功與否的信息給TM。
　　2）commit 階段
　　事務管理器收到回應后進入第二階段，如果在第一階段內有任何一個數據庫的操作發生了錯誤，或者事務管理器收不到某個數據庫的回應，則認為事務失敗，回撤所有數據庫的事務。數據庫服務器收不到第二階段的確認提交請求，也會把"可以提交"的事務回撤。如果第一階段中所有數據庫都提交成功，那么事務管理器向數據庫服務器發出"確認提交"請求，數據庫服務器把事務的"可以提交"狀態改為"提交完成"狀態，然后返回應答。即：為事務提交或者回滾階段，如果TM收到所有RM的成功消息，則TM向RM發出提交指令；不然則發出回滾指令。

　　2.2. redo與binlog的一致性問題
　　我們MySQL為了兼容其它非事務引擎的復制，在server層面引入了 binlog, 它可以記錄所有引擎中的修改操作，因而可以對所有的引擎使用復制功能；然而這種情況會導致redo log與binlog的一致性問題；MySQL通過內部XA機制解決這種一致性的問題。
　　第一階段：InnoDB prepare， write/sync redo log；binlog不作任何操作；
　　第二階段：包含兩步，1> write/sync Binlog； 2> InnoDB commit (commit in memory)；
　　當然在5.6之后引入了組提交的概念，可以在IO性能上進行一些提升，但總體的執行順序不會改變。
　　當第二階段的第1步執行完成之后，binlog已經寫入，MySQL會認為事務已經提交并持久化了(在這一步binlog就已經ready并且可以發送給訂閱者了)。在這個時刻，就算數據庫發生了崩潰，那么重啟MySQL之后依然能正確恢復該事務。在這一步之前包含這一步任何操作的失敗都會引起事務的rollback。
　　第二階段的第2大部分都是內存操作，比如釋放鎖，釋放mvcc相關的read view等等。MySQL認為這一步不會發生任何錯誤，一旦發生了錯誤那就是數據庫的崩潰，MySQL自身無法處理。這個階段沒有任何導致事務rollback的邏輯。在程序運行層面，只有這一步完成之后，事務導致變更才能通過API或者客戶端查詢體現出來。

（編輯：武林網）

上一篇：pt-online-schema-change 在線修改表構架

下一篇：返回列表