說MGR - 全局事務(wù)認(rèn)證模塊&異地事務(wù)執(zhí)行模塊

全局事務(wù)認(rèn)證模塊

全局事務(wù)認(rèn)證模塊有一個(gè)消息隊(duì)列，用來存放收到的消息。這些消息主要是事務(wù)的Binlog Event，也有一部分狀態(tài)和控制消息。狀態(tài)表replication_group_member_stats中的字段COUNT_TRANSACTIONS_IN_QUEUE指的就是這個(gè)隊(duì)列中的事務(wù)數(shù)量。

全局事務(wù)認(rèn)證模塊的核心任務(wù)是做沖突檢測(cè)，識(shí)別出那些同時(shí)修改了同樣數(shù)據(jù)的事務(wù)，并做出相應(yīng)的處理。沖突檢測(cè)時(shí)需要的信息包括三點(diǎn)。

·主鍵信息。

·事務(wù)執(zhí)行時(shí)數(shù)據(jù)庫的快照版本。

·執(zhí)行事務(wù)的MySQL實(shí)例的UUID。

沖突檢測(cè)需要的信息

MGR的沖突檢測(cè)中以數(shù)據(jù)行為單位，兩個(gè)事務(wù)是不是修改了同樣的數(shù)據(jù)，是通過事務(wù)所修改的主鍵值來判斷的。當(dāng)發(fā)現(xiàn)兩個(gè)事務(wù)修改了同樣的數(shù)據(jù)后，如何來判斷這兩個(gè)事務(wù)是不是同時(shí)執(zhí)行呢？這里用到了數(shù)據(jù)庫快照版本。數(shù)據(jù)庫快照是數(shù)據(jù)庫的一個(gè)瞬時(shí)狀態(tài)，每個(gè)寫操作都會(huì)導(dǎo)致數(shù)據(jù)庫狀態(tài)的變化，不同的狀態(tài)用不同的快照版本來表示?？煺瞻姹臼怯肎TID來表示的，每個(gè)寫事務(wù)都會(huì)產(chǎn)生一個(gè)唯一的GTID，這個(gè)GTID由全局事務(wù)認(rèn)證模塊產(chǎn)生，且在事務(wù)提交時(shí)會(huì)被添加到全局變量gtid_executed中。因此，gtid_executed的內(nèi)容就是MySQL數(shù)據(jù)庫的快照版本。

沖突檢測(cè)數(shù)據(jù)庫

全局事務(wù)認(rèn)證模塊中還維護(hù)了一個(gè)沖突檢測(cè)數(shù)據(jù)庫，它是主鍵哈希+快照版本的列表。快照版本存儲(chǔ)的是最后一個(gè)修改此主鍵事務(wù)的快照版本加上這個(gè)事務(wù)的GTID。收到事務(wù)信息后，全局事務(wù)認(rèn)證模塊會(huì)根據(jù)Transaction_context_log_event中的主鍵信息，從沖突檢測(cè)數(shù)據(jù)庫中檢索出所有主鍵的快照版本和該事務(wù)的快照版本進(jìn)行對(duì)比。當(dāng)前事務(wù)的快照版本必須要包含檢索出的所有主鍵快照版本中的GTID，否則就是有沖突。

沖突處理

沖突檢測(cè)完成后，全局認(rèn)證模塊接下來的處理是有本地事務(wù)和異地事務(wù)區(qū)分的。Transaction_context_log_event中記錄了產(chǎn)生這個(gè)事務(wù)的MySQL實(shí)例的UUID。根據(jù)這個(gè)UUID，就能判斷出這是一個(gè)本地事務(wù)還是異地事務(wù)。對(duì)于本地事務(wù)處理如下。

·如果沒有沖突，喚醒這個(gè)事務(wù)的線程，并且告訴它完成提交操作。

·如果有沖突，喚醒這個(gè)事務(wù)的線程，并且告訴它發(fā)生沖突，需要回滾。

·不論是否有沖突，Binlog Event都會(huì)被丟棄。

對(duì)于異地事務(wù)的處理如下。

·如果沒有沖突，將這個(gè)事務(wù)的Binlog Event寫入Relay log中，讓group_replication_applier通道去執(zhí)行。

·如果有沖突，則丟棄這個(gè)事務(wù)的Binlog Event。

沖突檢測(cè)數(shù)據(jù)庫的清理

隨著使用時(shí)間越來越長(zhǎng)，沖突檢測(cè)數(shù)據(jù)庫中維護(hù)的主鍵信息會(huì)越來越多，會(huì)占用大量?jī)?nèi)存。為了減少內(nèi)存的使用并提高查詢效率，全局事務(wù)認(rèn)證模塊需要定期的清理沖突檢測(cè)數(shù)據(jù)庫。如果一個(gè)事務(wù)已經(jīng)在所有成員上執(zhí)行了，其它事務(wù)的執(zhí)行肯定不會(huì)和它有沖突，因此這個(gè)事務(wù)的所有主鍵信息就可以從沖突檢測(cè)數(shù)據(jù)庫中移除。主鍵信息的清理是依據(jù)成員上的全局變量gtid_executed中的GTID集合來做的。全局認(rèn)證模塊啟動(dòng)了一個(gè)廣播線程，每60秒將自己的gtid_executed中的GTID集合廣播到所有成員上。全局認(rèn)證模塊收到所有成員的GTID集合后，取它們的交集。這個(gè)交集中包含的就是那些已經(jīng)在所有成員上執(zhí)行了的事務(wù)GTID的集合，稱作全局完成的GTID集合（replication_group_member_stats表中的TRANSACTIONS_COMMITTED_ALL_MEMBERS顯示的就是全局完成的GTID集合。）。全局事務(wù)認(rèn)證模塊會(huì)將沖突檢測(cè)數(shù)據(jù)庫所有主鍵的快照版本和全局完成的GTID集合進(jìn)行對(duì)比，如果快照版本GTID集合是全局完成的GTID集合的子集，則這個(gè)主鍵的信息就會(huì)從沖突檢測(cè)數(shù)據(jù)庫中清除掉。

異地事務(wù)執(zhí)行模塊

為了執(zhí)行異地事務(wù)的Binlog Event，MGR會(huì)自動(dòng)創(chuàng)建一個(gè)名為group_replication_applier的通道。這個(gè)通道的Receiver線程是關(guān)閉的，不會(huì)從其它成員上去復(fù)制Binlog Event。所有的Binlog Event都是由全局事務(wù)認(rèn)證模塊通過API寫入Relay log的。

事務(wù)流程的總結(jié)

事務(wù)在MGR中的執(zhí)行過程可以總結(jié)為以下三個(gè)部分。

·網(wǎng)絡(luò)傳輸。

·事務(wù)在本地的執(zhí)行過程。

·事務(wù)在異地的執(zhí)行過程。

網(wǎng)絡(luò)傳輸

MGR通過Paxos協(xié)議來傳播事務(wù)信息。Paxos保障所有的事務(wù)信息按照同樣的順序傳播到所有成員上。

事務(wù)在本地成員上的執(zhí)行過程

事務(wù)在本地提交時(shí)（prepare之后，寫B(tài)inlog之前），將事務(wù)信息發(fā)送至通信模塊，然后開始等待事務(wù)認(rèn)證結(jié)果。通信模塊將事務(wù)排序后發(fā)送到本地成員的全局事務(wù)認(rèn)證模塊。全局事務(wù)認(rèn)證模塊做完沖突檢測(cè)后，喚醒該事務(wù)繼續(xù)執(zhí)行，或回滾。

事務(wù)在異地成員上的執(zhí)行過程

通訊模塊將事務(wù)排序后發(fā)送到全局事務(wù)認(rèn)證模塊。全局事務(wù)認(rèn)證模塊認(rèn)證成功后，將該事務(wù)的Binlog Event寫入Relay log，由group_replication_applier通道來執(zhí)行。如果全局事務(wù)認(rèn)證模塊認(rèn)證失敗，則會(huì)丟棄該事務(wù)的Binlog Event。