What are the three replication modes of Mysql master and slave?

MySQL Asynchronous Replication

MySQL asynchronous replication is the default replication mode during the master-slave replication process. Replication involves three threads, including the master I/O thread, the slave I/O thread, and the slave SQL thread. Because it is asynchronous replication, the submission of the master transaction does not need to be confirmed by the slave. That is, after the master I/O thread submits the transaction, it does not need to wait for the reply confirmation from the slave I/O thread. The master does not guarantee that the binlog will be written to the relay. in the log; after slave I/O writes the binlog to the relay log, it is asynchronously executed by the slave sql thread and applied to slave mysql. Slave I/O does not require reply confirmation from slave sql, and does not guarantee that the relay log is completely written. In mysql.

Semi-synchronous replication

In order to make up for the shortcomings of traditional asynchronous replication, MySQL introduced semi-synchronous replication in version 5.5, which is an improvement over traditional asynchronous replication. . Before the master transaction is committed, it must be ensured that the binlog log has been written to the slave's relay log. Only after receiving the response from the slave to the master can the transaction be committed. Despite this, the second half of the relay log will still be passed to the sql thread for execution asynchronously.

##Group Replication

Based on the defects of traditional asynchronous replication and semi-synchronous replication-data consistency cannot be guaranteed, MySQL official in 5.7. Version 17 officially launches group replication (MySQL Group Replication, referred to as MGR).

A replication group is composed of several nodes. The submission of a transaction must be resolved and approved by the majority of nodes in the group (N / 2 1) before it can be submitted. As shown in the figure above, a replication group consists of 3 nodes. The Consensus layer is the consistency protocol layer. During the transaction submission process, inter-group communication occurs. Only when 2 nodes resolve (certify) the transaction, the transaction can finally be resolved. Submit and respond.

The main purpose of introducing group replication is to solve the data inconsistency problem caused by traditional asynchronous replication or semi-synchronous replication. Group replication relies on the distributed consistency protocol (a variant of the Paxos protocol) to achieve the ultimate consistency of distributed data and provide a true data high availability solution (whether it is truly highly available remains to be discussed). The multi-write solution it provides brings hope to us to achieve a multi-active solution.

In the MGR environment, the number of servers must be more than 3 and an odd number to implement the 2/n 1 algorithm.

A replication group consists of several nodes (database instances). Each node in the group maintains its own copy of data (Share Nothing), and implements atomic messages and Global ordered messages to achieve consistency of instance data within the group.

MGR’s solution now has features

Data consistency guarantee:Ensure that most nodes in the cluster receive logs

Node writing support:In multi-write mode, all nodes in the cluster can be written (but considering the 1 to high concurrency scenario to ensure high data consistency, production does not choose multi-master writing, use single master Cluster)

Fault Tolerance:Ensure that the system is still available when it fails (including split brain), and double writing has no impact on the system

The current impact of MGR's solution

• Only supports InnoDB tables, and each table must have a primary key for conflict detection of write set;

• The GTID feature must be turned on , the binary log format must be set to ROW, used for primary selection and write set

• COMMIT may cause failure, similar to the failure scenario of the snapshot transaction isolation level

• Currently, an MGR cluster supports up to 9 nodes

• Does not support foreign keys and save point features, and cannot perform global constraint detection and partial rollback

• Binary log does not support binlog event checksum

The above is the detailed content of What are the three replication modes of Mysql master and slave?. For more information, please follow other related articles on the PHP Chinese website!