What are the advantages of MySQL MGR?

MGR (MySQL Group Replication) is a new feature added in version 5.7 and is a MySQL plug-in.

MGR is a new high-availability and high-scalability solution. The data of any node in the cluster is the same, and any node can be written, realizing true multi-master.

It mainly includes the following parts:

API layer: responsible for completing the interaction with MySQL Server, obtaining the Server status, and completing transaction management.

Component layer: mainly includes three specific components. Capture is responsible for collecting relevant information of transaction execution, Applier is responsible for applying cluster transactions to local, and Recovery is responsible for node data recovery.

Replication layer: responsible for conflict verification, receiving and applying cluster transactions.

Cluster communication layer: Cluster communication engine based on the Paxos protocol and interaction interface with upper-layer components.

MGR Group Replication:

Based on the defects of traditional asynchronous replication and semi-synchronous replication - data consistency cannot be guaranteed, MySQL officially launched Group Replication (MySQL Group Replication, MGR for short) in version 5.7.17.

A replication group is composed of several nodes. The submission of a transaction must be decided and passed by the majority of nodes (N/2 + 1) in the group before it can be submitted. As shown in the figure above, a replication group is composed of three nodes. The Consensus layer is the consistency protocol layer. During the transaction submission process, inter-group communication occurs. The transaction can only be submitted and responded to after two nodes have approved it.

The introduction of group replication is mainly to solve the problem of data inconsistency that may occur in traditional asynchronous replication and semi-synchronous replication. Group replication relies on a distributed consistency protocol (a variant of the Paxos protocol) to achieve eventual consistency of data in a distributed environment and provide a truly high-availability data solution (whether it is truly highly available remains to be discussed). The multi-write solution it provides brings us hope of realizing a multi-active solution.

MGR implements a distributed database architecture, and the underlying distributed foundation is the Paxos protocol. Paxos is used to ensure the submission order of transactions in distributed database systems. Although MGR will use the Slave channel, it only uses the execution thread (Applier Thread) of this channel to execute the Binlog Event sent remotely, and does not use this channel to transmit the Binlog Event. MGR does not use the Binlog Event transmission mechanism of asynchronous replication, nor does it use the MySQL service port for communication. MGR creates an independent TCP port for communication. The Group Replication plug-ins on each MySQL server are connected together through this port, and can communicate directly with each other.

The transmission of Binlog Event is not a simple point-to-point transmission like asynchronous replication. MGR uses the Paxos protocol when transmitting data. The Paxos protocol ensures the consistency and atomicity of data transmission. MGR builds a distributed state machine replication mechanism based on the Paxos protocol, which is the core technology for implementing multi-master replication.

Three main advantages:

1. Avoid split-brain: Split-brain will not occur in MGR (but be aware that network partitions may occur. MGR behaves slightly differently depending on the setting of the parameter group_replication_unreachable_majority_timeout=0/N).

2. Data consistency guarantee: MGR has excellent redundancy capabilities, which can ensure that Binlog Events are replicated to at least more than half of the members. As long as no more than half of the members fail at the same time, data loss will not occur. MGR also ensures that as long as the Binlog Event is not transmitted to more than half of the members, the local member will not write the transaction's Binlog Event into the Binlog file and commit the transaction, thereby ensuring that the downed server will not have data that does not exist on the online members in the group. Therefore, after a downed server is restarted, it can join the group without any special processing.

3. Multi-node write support: In multi-write mode, all nodes in the cluster can be written.

The above are the details of the advantages of MySQL MGR. For more information about MySQL MGR, please pay attention to other related articles on 123WORDPRESS.COM!