Shulou(Shulou.com)06/01 Report--

Global transaction authentication module

The global transaction authentication module has a message queue for storing received messages. These messages are mainly the Binlog Event of the transaction, as well as some status and control messages. The field COUNT_TRANSACTIONS_IN_QUEUE in the status table replication_group_member_stats refers to the number of transactions in this queue.

The core task of the global transaction authentication module is to do conflict detection, identify those transactions that modify the same data at the same time, and deal with them accordingly. The information needed for conflict detection includes three points.

Primary key information.

The snapshot version of the database when the transaction is executed.

The UUID of the MySQL instance that performed the transaction.

Information needed for conflict detection

The conflict detection of MGR is based on the data behavior unit. Whether the two transactions modify the same data is judged by the primary key value modified by the transaction. When it is found that two transactions have modified the same data, how to determine whether the two transactions are executed at the same time? The database snapshot version is used here. Database snapshot is an instantaneous state of the database, each write operation will lead to changes in the state of the database, different states are represented by different versions of the snapshot. The snapshot version is represented by GTID, and each write transaction produces a unique GTID, which is generated by the global transaction authentication module and is added to the global variable gtid_executed when the transaction commits. Therefore, the content of gtid_executed is a snapshot version of the MySQL database.

Conflict detection database

A conflict detection database is also maintained in the global transaction authentication module, which is a list of primary key hash + snapshot versions. The snapshot version stores the last snapshot version that modifies the primary key transaction plus the GTID of the transaction. After receiving the transaction information, the global transaction authentication module will compare the snapshot version of all primary keys and the snapshot version of the transaction from the conflict detection database according to the primary key information in Transaction_context_log_event. The snapshot version of the current transaction must contain the GTID in all the primary key snapshot versions retrieved, otherwise there is a conflict.

Conflict handling

After the conflict detection is completed, the next processing of the global authentication module is distinguished between local transactions and remote transactions. The UUID of the MySQL instance that generated the transaction is recorded in Transaction_context_log_event. Based on this UUID, you can tell whether this is a local transaction or a remote transaction. For local transactions, this is as follows.

If there is no conflict, wake up the thread of the transaction and tell it to complete the commit operation.

If there is a conflict, wake up the thread of the transaction and tell it that there is a conflict and needs to be rolled back.

Binlog Event is discarded regardless of whether there is a conflict or not.

The handling of off-site transactions is as follows.

If there is no conflict, write the Binlog Event of the transaction to Relay log and let the group_replication_applier channel execute.

If there is a conflict, the transaction's Binlog Event is discarded.

Cleaning of conflict detection database

With the longer and longer use time, the primary key information maintained in the conflict detection database will be more and more, which will take up a lot of memory. In order to reduce the use of memory and improve the query efficiency, the global transaction authentication module needs to clean up the conflict detection database regularly. If a transaction has been executed on all members, the execution of other transactions will certainly not conflict with it, so all primary key information for this transaction can be removed from the conflict detection database. The cleaning of primary key information is based on the GTID collection in the global variable gtid_executed on the member. The global authentication module starts a broadcast thread that broadcasts its own GTID collection in gtid_executed to all members every 60 seconds. After receiving the GTID set of all members, the global authentication module takes their intersection. This intersection set contains a collection of transactions GTID that have been executed on all members, called the globally completed GTID set (the TRANSACTIONS_COMMITTED_ALL_MEMBERS in the replication_group_member_ stats table shows the globally completed GTID collection. ). The global transaction authentication module compares the snapshot version of all primary keys of the conflict detection database with the globally completed GTID collection. If the snapshot version GTID collection is a subset of the globally completed GTID collection, the information of this primary key will be purged from the conflict detection database.

Remote transaction execution module

In order to perform remote transactions, Binlog Event,MGR automatically creates a channel called group_replication_applier. The receiver thread for this channel is turned off and Binlog Event is not copied from other members. All Binlog Event are written to Relay log through API by the global transaction authentication module.

Summary of transaction process

The execution of a transaction in MGR can be summarized into the following three parts.

Network transmission.

The local execution of a transaction.

The execution of a transaction in a different place.

Network transmission

MGR propagates transaction information through the Paxos protocol. Paxos ensures that all transaction information is propagated to all members in the same order.

The execution of a transaction on a local member

When the transaction is committed locally (after prepare, before writing Binlog), the transaction information is sent to the communication module, and then starts waiting for the transaction authentication result. The communication module sorts the transactions and sends them to the global transaction authentication module of the local member. After the global transaction authentication module completes conflict detection, it wakes up the transaction to continue execution, or rolls back.

The execution process of a transaction on a remote member

The communication module sorts the transactions and sends them to the global transaction authentication module. After the authentication of the global transaction authentication module is successful, the Binlog Event of the transaction is written to Relay log and executed by the group_replication_applier channel. If the global transaction authentication module fails authentication, the Binlog Event of the transaction is discarded.

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.