This is the 7th day of my participation in the August Text Challenge.More challenges in August

We mentioned three modes of MySQL replication earlier, so let’s talk about how group replication works and the program structure.

How group replication works

MySQL group replication is a MySQL plug-in that builds on the existing MySQL replication infrastructure and utilizes binary logging, row-based logging, and global transaction identifiers. It integrates current MySQL frameworks such as performance patterns, plug-ins, and service infrastructure.

Group Replication, based on the distributed consistency algorithm (a variant of the Paxos protocol), is a technique used in fault-tolerant systems where a Group allows some nodes to fail but is still available as long as most of the nodes are still alive and communication between them is fine. \

A Group Replication is composed of multiple servers (nodes) that can communicate with each other. At the communication layer, Group Replication implements a number of mechanisms, such as atomic message delivery and total ordering of messages. These atomized and abstract mechanisms provide powerful support for more advanced database replication solutions. MySQL Group Replication implements a multi-master full update Replication protocol based on these technologies and concepts. To put it simply, a Group Replication is a Group of nodes, each of which can execute transactions independently, while read and write transactions are committed after the other nodes in the Group have coordinated. Therefore, when a transaction is ready to commit, atomic broadcasts are automatically made within the group to inform other nodes of what has changed/what transaction has been executed. This atomic broadcasting keeps the transaction in the same order at each node. This means that each node receives the same transaction logs in the same order, so each node replays the transaction logs in the same order, and eventually the entire group remains in exactly the same state. However, there can be resource contention between transactions executed on different nodes. This phenomenon tends to occur with two different concurrent transactions. Suppose there are two concurrent transactions on different nodes updating the same row of data, then resource contention occurs. In this case, Group Replication determines that the first committed transaction is a valid transaction and replays it across the Group, while the second committed transaction is either directly interrupted or rolled back, and finally discarded. Therefore, this is also a share-free replication scheme, where each node holds a complete copy of the data. \

As you can see from how it works, Group Replication’s consistency algorithm based on the Paxos protocol verifies that transactions are executed for conflicts and then executes them sequentially to achieve data consistency, which means that some nodes can have delays. Group_replication_single_primary_mode is used to control multiple primary writes and single primary writes. Single primary writes are recommended. However, if the delay is too long, the traffic limiting rule (configurable) is triggered and the cluster slows down. Performance is compromised.

The program structure for group replication

At the bottom of MySQL, GR adds an additional API layer to implement the required functionality. Programmatically, GRAPI is divided into three parts:

  • 1: Capture tracks the context of the transaction currently being executed. ,

  • 2: Applier performs remote transactions to transfer logs locally to the local database. ,

  • 3: Recovery Is responsible for node recovery, data recovery, and failure handling in the distributed environment.

    Underneath these main API layers is the unified replication protocol logic processing layer, which is used to unify the various calls of the application layer. At the lower level, there is the distributed communication layer with higher general degree, which is in the call convenience. The DISTRIBUTED communication used to provide the API on the top, and below the API, is the distributed communication protocol component implemented by Paxos, which together with other nodes in the cluster, forms a virtual and conceptual distributed cluster.