In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
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.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.