Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

What is the execution process of a transaction in MGR

2025-02-25 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >

Share

Shulou(Shulou.com)05/31 Report--

This article shows you how the execution process of transactions in MGR is, the content is concise and easy to understand, and it will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

The most important function of the group_replication plug-in in MGR is the function of the transaction dispenser, where it distributes Binlog Event, and the transaction dispenser is processed at the end of the transaction execution. MGR calls this an optimistic transaction execution strategy that can lead to better performance. However, under this strategy, transactions on multiple members may conflict. MGR needs a conflict detection mechanism to find and handle conflicts. According to the different processing steps in the transaction process, the function of the transaction dispenser in MGR is divided into the following four parts.

Local transaction control module

Communication module between members

Global transaction authentication module

Remote transaction execution module

First, let's take a look at the local transaction control module. MySQL provides the plug-in with Hook interfaces for several important stages of transaction execution through API, and MGR monitors and controls transaction execution through these interfaces. When a MySQL transaction commits, it is internally divided into three phases: the prepare phase, the recording binlog file phase, and the commit phase. MGR's control logic for local transactions is executed in the interface before_commit. The before_commit is executed after the prepare phase of the transaction and before the write binlog file phase. Control of local transactions consists of the following three steps.

1. Send transaction information

MGR first packages the information related to transaction execution and sends it to the local communication module through the interface of the communication module. As long as the local communication module receives the message, it will return to success (sending to other members is the responsibility of the communication module among members). Transaction information includes primary key information, database snapshot version, and Binlog Event generated by the transaction.

The primary key information is generated together with the Binlog Event generated by the Server layer. What is recorded in the primary key information is not the value of the primary key field, but the field value plus the hash value of the library name, table name, and so on.

The database snapshot version is the value of the global variable gtid_executed of the current MySQL. It contains the GTID of all transactions that have been executed when the current transaction is committed, representing the state of the database when the current transaction is executed.

Binlog Event has not yet written to the Binlog file when the transaction information is sent. Therefore, the Binlog Event is obtained from the Binlog Cache of the current thread and does not depend on the Binlog file.

Transaction_context_log_event, the UUID, primary key information, and database snapshot version of the local member are encapsulated in Transaction_context_log_event and sent out together with the Binlog Event generated by the transaction. Transaction_context_log_event is placed in front of the other Binlog Event.

two。 Waiting for the authentication result of the global transaction authentication module

After the transaction information is sent successfully, the transaction will be blocked and begin to wait for the authentication result of the global transaction authentication module. After the transaction authentication is completed, the global transaction authentication module will wake up the thread of the current transaction and let the transaction continue to execute.

3. Processing of authentication results

After the transaction continues, the authentication result is detected. If the authentication is successful, continue to commit the transaction. If the authentication fails, an error is returned. MySQL then executes the logic of the Rollback.

The above is what the execution of a transaction in MGR is like. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report