MGR中事務的執行過程是怎樣的

本篇文章為大家展示了MGR中事務的執行過程是怎樣的，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

MGR中group_replication插件最重要的功能就是事務分發器的功能，這里其分發的是Binlog Event，事務分發器的處理是在事務執行即將結束的時候。MGR將這稱作樂觀的事務執行策略，可以帶來更好的性能。但這種策略下，多個成員上的事務可能發生沖突。MGR需要一個沖突檢測機制來發現并處理沖突。根據事務處理過程中的不同處理步驟，MGR中事務分發器的功能劃分為以下四個部分。

·本地事務控制模塊

·成員間的通信模塊

·全局事務認證模塊

·異地事務執行模塊

先來看下本地事務控制模塊，MySQL通過API向插件提供了事務執行過程中幾個重要階段的Hook接口，MGR通過這些接口來監控和控制事務的執行。MySQL的事務在提交時，內部會分成三個階段：準備（prepare）階段，記錄binlog文件階段和提交（commit）階段。MGR對本地事務的控制邏輯在before_commit這個接口中執行。before_commit是在事務的prepare階段之后，寫binlog文件階段之前被執行的。對本地事務的控制包括以下三個步驟。

1.發送事務信息

MGR首先將事務執行相關的信息打包，通過通信模塊的接口發送給本地的通信模塊，只要本地的通信模塊接收到了消息就返回成功（發送到其它成員是成員間通信模塊的職責）。事務信息包括主鍵信息、數據庫快照版本和事務產生的Binlog Event。

·主鍵信息是Server層生成Binlog Event的時候一同生成的。主鍵信息中記錄的并不是主鍵字段的值，而是字段值加上庫名、表名等哈希值。

·數據庫快照版本是當前MySQL的全局變量gtid_executed的值。它包含了當前事務提交時所有已經執行了的事務的GTID，代表了當前事務執行時數據庫的狀態。

·當發送事務信息時，Binlog Event還沒寫入Binlog文件。因此，Binlog Event是從當前線程的Binlog Cache中獲取的，而不依賴Binlog文件。

·Transaction_context_log_event，本地成員的UUID、主鍵信息和數據庫快照版本會被封裝進Transaction_context_log_event中，和事務產生的Binlog Event一起發出去。Transaction_context_log_event放在其它Binlog Event的前面。

2.等待全局事務認證模塊的認證結果

在事務信息發送成功后，事務會被阻塞，開始等待全局事務認證模塊的認證結果。事務認證完成后，全局事務認證模塊會喚醒當前事務的線程，讓事務繼續執行。

3.認證結果的處理

事務繼續執行后，會檢測認證結果。如果認證成功了，就繼續提交事務。如果認證失敗了，就會返回錯誤。然后由MySQL來執行Rollback的邏輯。

上述內容就是MGR中事務的執行過程是怎樣的，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。