【MySQL 之Group Replication】

MySQL Group Replication is a MySQL Server plugin that provides distributed state machine replication with strong coordination between servers. Servers coordinate themselves automatically, when they are part of the same replication group.

 

 

Generally, master-slave replication involves three threads, all of which are single-threaded: Binlog Dump (master) -----> IO Thread (slave) -----> SQL Thread (slave). Replication delays generally occur in two places

1) The SQL thread is too busy (may need to apply a large amount of data, and there may be lock and resource conflicts with some operations of the slave library itself; the main library can write concurrently, but the SQL thread cannot; the main reason)

2) Network jitter causes IO thread replication delay ( secondary cause).

 

 

In MySQL 5.6, set the parameter slave_parallel_workers = 4 (>1), you can have 4 SQL Threads (coordinator threads) for parallel replication, and its status is: Waiting for an evant from Coordinator. But its parallelism is only based on Schema, that is, based on library. If there are multiple schemas in the database instance, this setting can greatly improve the speed of slave replication. Usually, a single database with multiple tables is a more common situation, so the library-based concurrency is useless. The core idea is that the data of the concurrent submission of tables under different schemas will not affect each other, that is, the slave node can use a thread similar to SQL function to each different schema in the relay log to replay the main library in the relay log. The committed transaction keeps the data consistent with the main database.

 

In MySQL 5.7, parallel replication based on group submission (Enhanced Multi-threaded Slaves) was introduced, setting the parameter slave_parallel_workers>0 and global.slave_parallel_type='LOGICAL_CLOCK', can support a schema, slave_parallel_workers worker threads execute relay concurrently Transactions submitted by the main library in the log. Its core idea: transactions submitted by a group can be played back in parallel (with binary log group commit); transactions with the same last_committed (different sequence_num) in the relay log of the slave machine can be executed concurrently.

 

 

Group Replication

Group replication is a technique that can be used to implement fault-tolerant systems. A replication group is a group of servers that interact with each other through messaging. The communication layer provides many guarantees, such as the delivery of atomic messages and total message sequence numbers. With these powerful features, we can build more advanced database replication solutions.

MySQL Group Replication builds on these properties and abstractions and implements updates to the multi-master replication protocol. Essentially, a replication group consists of multiple database instances, and each instance in the group can execute transactions independently. But all read-write (RW) transactions are committed only after being approved by the group. Read-only (RO) transactions do not need to be coordinated within the group and therefore commit immediately. In other words, for any RW transaction, the group needs to decide whether to commit, so the commit operation is not a one-way decision from the originating server. Precisely, when a transaction is ready to commit on the originating server, the originating server atomically broadcasts the write value (the changed row) and the corresponding write set (the unique identifier of the updated row). A global total sequence number is then established for the transaction. Ultimately, this means that all servers receive the same set of transactions in the same order. Therefore, all servers apply the same set of changes in the same order, so they remain consistent within the group.

 

However, there may be conflicts between transactions executing concurrently on different servers. Such conflicts are detected by examining the write sets of two different concurrent transactions, a process called certification. A conflict occurs if two concurrent transactions executing on different servers update the same row. The parsing process does this, and transactions initiated first are committed on all servers, and transactions initiated later are rolled back on the origin server and deleted by other servers in the group. This is actually a "first submitter wins" rule in a distributed environment.

Finally, Group Replication is a shared-nothing replication scheme (shared_nothing), where each server has its own copy of the entire data. The above diagram depicts the MySQL Group Replication protocol, and by comparing it to MySQL Replication (or even MySQL Semi-Sync Replication) you can see some of the differences. Note that some basic consensus and Paxos related information is missing from this image for clarity.

 

 

Group ReplicationUse Cases

Group Replication enables you to create a fault-tolerant system with redundancy by replicating the system state across a group of servers. Therefore, even if some servers fail, as long as it is not all or most, the system is still available, although it may reduce system performance or scalability. Single server failures are isolated and independent. They are tracked by the group membership service, which relies on a distributed failure detector capable of signaling when any node member leaves the group, either voluntarily or due to an unexpected stop. The distributed recovery process ensures that when a new node joins the group, that node is automatically updated to the latest. The Multi-master feature ensures that updates are not blocked even in the event of a single server failure. Therefore, MySQL Group Replication guarantees continuous availability of database services.

 

It's important to understand, though, that while Group Replication is highly available, clients connecting to it must be redirected or failed over to a different server. This is not the problem that Group Replication is trying to solve, but rather that a connector, load balancer, router or some other middleware is better suited to handle this.

 

All in all, MySQL Group Replication provides a highly available, highly resilient, reliable MySQL service.

 

Examples of Use Case Scenarios

Elastic Replication - Environments that require a very fluid replication infrastructure, where the number of servers must grow or shrink dynamically, with as few side effects as possible. For example, cloud database services.

High Availability Sharding - Sharding is a common way to achieve write scaling. High availability shards are implemented using MySQL Group Replication, where each shard is mapped to a replication group.

• Alternative to master-slave replication - in some cases, using a single master may make it a single point of contention. In some cases, it may be more scalable to write to the entire group.

Automated systems - MySQL Group Replication can be used as a purely automated replication system

 

 

 

 

Some limitations in group replication

1 data table to use innodb storage

2 There must be a primary key on the table

3 Use ipv4

4 The performance of the network is better

5 Copy the pattern you want to use row copying

6gtid mode to open

7 transaction savepoints are not supported

8 Foreign keys are not supported on multiple masters

9 Serializable transaction isolation level on multiple masters will not be supported 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326352081&siteId=291194637