Introduction to MGR
MySQL Group Replication, referred to as MGR, is a state machine replication officially launched by MySQL based on the paxos distributed consistency protocol, which realizes the ultimate consistency of data under distributed conditions. At the same time, MGR provides a highly available, highly scalable, and highly reliable MySQL cluster solution. It is also one of the financial-grade distributed databases.
MGR applicable scenarios
MGR is inherently designed for financial scenarios, such as: payment, securities trading, insurance, banking, and so on. Because these scenarios require zero data loss, the database availability is 4 9s or even 5 9s (annual downtime does not exceed 5 minutes).
MGR uses multiple copies. In a 2N+1 node cluster, as long as N+1 nodes in the cluster are still alive, the database can provide services stably.
MGR operation mode
There are 2 MGR operation modes
-
Single-primary mode
- Multi-primary mode
Single-master mode:
In this mode, the group has a single-master server set to read-write mode. All other members in this group are set to read-only mode. This will happen automatically. The master server is usually the first server to boot the group. All other servers that join will automatically learn about the master server and set it as read-only.
Multi-primary mode:
In the multi-primary mode, there is no single main concept. No need to participate in the election process, because no server plays any special role,
All servers are set to read-write mode.
MGR election principle
MGR single-master mode election principle In
single-master mode, if the master node goes down, other members will automatically elect a new master member. The members can determine who the next master member is by configuring weights. If If no weight is configured, the UUIDs of all online members will be sorted, and then the member with the smallest UUID will be selected as the main member.
MGR multi-primary mode election principle
Multi-primary mode, all members of the group provide external read and write services, which is concurrency in the true sense, and MGR has good processing capabilities for high concurrency. In the multi-master mode, all members in the group have no master-slave distinction. For the user, it is like operating a MySQL. Therefore, in the multi-master mode, there is no election of master nodes, because all nodes are master nodes.
MGR replication principle
In a single-master mode group replication cluster composed of 2N+1 nodes, when a transaction in the main database is committed, the information related to the transaction modification record and the BINLOG event generated by the transaction will be packaged to generate a write set (WRITE SET) , Send the write set to all nodes, and pass at least N nodes to vote for the transaction to be successfully submitted.
MGR requirements
1. Innodb storage engine must be used
2. The business table created must have a primary key
3. MGR must be applicable to an IPv4 network and does not support IPv6
4. The MGR replication network must be isolated from the business network
5. The binlog log format must be row mode
6. Turn off binary log checksum and set --binlog-checksum=NONE
7. Lower case table cell name. Set --lower-case-table-names to the same value on all group members.
8. Set the isolation level to RC
MGR restrictions
1. MGR does not support SERIALIZABLE isolation level
2. MGR cluster nodes cannot exceed 9
3. MGR does not support large transactions, the transaction size should not exceed 143MB, when the transaction is too large, it cannot be in the group through the network within 5 seconds If you copy messages between members, you may suspect that the member has failed, and then expel them from the game.
4. Concurrent DDL and DML operations. When using multi-primary mode, concurrent data definition statements and data operation statements for the same object but executed on different servers are not supported.
5. The foreign key support for the cascade constraint of the table is not good, and it is not recommended to apply.