從一個(gè)線上問題分析binlog與內(nèi)部XA事務(wù)提交步驟

2024-09-07 22:13:04

字體：大中小

供稿：網(wǎng)友

從一個(gè)線上問題分析binlog與內(nèi)部XA事務(wù)提交步驟：

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

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

（編輯：武林網(wǎng)）

上一篇：pt-online-schema-change 在線修改表構(gòu)架

下一篇：返回列表