Group Replication Routine Operations-Transaction Consistency Guarantee | A Comprehensive Understanding of MySQL 8.0 Group Replication

Author Luo Xiaobo·Database Technology Expert

Produced by Woqu Technology

For distributed systems such as group replication, one of the main requirements is that it needs to have data consistency guarantees. In other words, it is necessary to ensure the consistency of global synchronization of transactions distributed among group members. This section will introduce how group replication handles consistency guarantees based on events that occur in the group, and how to best configure group consistency guarantees.

4.2.1. Understanding transaction consistency guarantees
As far as distributed consistency guarantees are concerned, whether group replication is in normal or fault repair operations, it is always an eventually consistent system. This means that once the incoming group replication traffic slows down or stops, all group members will have the same data content. Events related to system consistency can be divided into: manual operations or control operations triggered automatically by faults, and data flow operations.
For group replication, control operations related to consistency include:
  • Add and remove group members. For the data consistency guarantee for adding and removing group members, please refer to "4.3. Distributed Recovery" for details.
  • Network failure protection.
  • Primary node failover: In the single-primary mode, the failover of the primary node also includes operations triggered by the group_replication_set_as_primary() function.
Primary node failover consistency protection
  • In a single-primary mode group, if the primary node fails over and a secondary node is promoted to the new primary node, there are two options for how the new primary node handles newly written transactions when there is a backlog of transactions Processing method: Regardless of the size of the transaction backlog, the newly written transactions are allowed to be processed immediately; access restrictions are performed in the new main node, and the newly written transactions are not processed until the backlog is completed by the application.
  • Use the first method: After the main node fails, in order to ensure that the group membership is stable in the shortest time (reconfigure the group view), the group will elect a new main node, and then the new main node When the old main node has a backlog of transactions, new transactions are allowed to be written immediately. This method can ensure write consistency, but before the new main node application completes the backlog of transactions, read operations may query stale data. For example: if client C1 successfully writes A=2 WHERE A=1 just before the old main node fails (change A=1 to A=2), then when client C1 reconnects to the new main node When the new primary node application completes the backlog of transactions and completely catches up with the state when the old primary node leaves the cluster, it may read A=1.
  • Use the second method: Compared with the first method, after the main node fails, a new main node will still be elected to protect the stable group membership, but the new main node needs to wait for full application After completing the backlog of transactions from the old primary node, new transactions are allowed to be written. This prevents the client C1 from reading stale data when connecting to the new main node. However, the price of this is that the time required for failover may be relatively long (the time required for failover is proportional to the size of the backlog of transactions), and the backlog of transactions should be kept small in a properly configured balanced group value.
  • Prior to MySQL 8.0.14, failover strategies were not supported, and the strategy for maximizing availability (the first method) was adopted by default. In MySQL 8.0.14 and later versions, the system variable group_replication_consistency can be used to configure the level of transaction consistency guarantee provided by group members during the failover of the primary node. For details, please refer to "4.2.2. Configuring Transaction Consistency Guarantee".
Data flow operation
  • Data flow is related to the consistency protection of read and write operations in the group, especially when these read and write operations are distributed among all members, the protection of data consistency is particularly important. Data flow operation is applicable to groups in single-master mode and multi-master mode. In the single-primary mode, the read-only transaction and the read-write transaction are usually split, the read-write transaction is routed to the main node, and the read-only transaction is evenly distributed to the remaining auxiliary nodes. For group replication, there may be multiple database servers, but for application access, it should provide services as a whole. Therefore, in theory, for applications, the data written on the main node can be Instant query on the secondary node. Although group replication is written using the Group Communication System (GCS) protocol based on the Paxos algorithm, some parts of the group replication process are asynchronous, which means that the transactions written by the primary node are applied asynchronously in the secondary node, so It may happen that the client C2 writes B=2 where B=1 on the primary node, and then the client C2 immediately connects to other secondary nodes to execute the query. It is read that B=1, this is because the transaction may be in a backlog state in the secondary node (the secondary node will not be applied in the future).
Transaction synchronization point (location)
  • When reading or writing a transaction, you can choose whether to configure strong data consistency of the group according to your needs. If strong data consistency of the group is configured, read-only transactions will not read stale data, and read-write transactions will not cause data delays in group members that do not initiate write transactions (configured through the system variable group_replication_consistency, details Refer to "4.2.2. Configuring Transaction Consistency Guarantee").
  • If you need to read data in real time, you can configure it to synchronize data while reading. The current client session will wait for a given point (the point in time when the application completes all previous update transactions) when performing read-only transactions. Will actually begin to execute. Using this method only affects the current session and does not affect all other concurrent data operations (read-only and read-write transactions).
  • If you synchronize data to other group members in real time while modifying data, you can configure to synchronize data when writing. When the client session executes read and write transactions, it will wait until all other secondary nodes have written their data . Since group replication follows a global order for write operations, this means that a read-write transaction needs to wait for all other member applications to complete all previously written transactions in their queues and the current written transaction.
  • Data synchronization during reading and data synchronization during writing. Both methods can ensure that the client C2 writes data on the primary node, and then connects to the secondary node to execute the query and cannot read the latest data. The problem. These two options have their own advantages and disadvantages. These advantages and disadvantages are directly related to the workload of the system. The following are some suggestions for choosing different data synchronization methods according to different workload types.
  • In these cases, you should choose to synchronize while writing.
    * The access in the group reads more and less writes. I hope to load balance the read operation. When reading from any read member, I hope to be able to read the latest data, and do not configure any member in the read load balancing. Limit to avoid reading stale data.
    * The access in the group reads more and writes less, and hopes to apply to all group members after the read and write transaction is committed, so that subsequent read operations can read the latest data (including the member that initiated the transaction write). This ensures that the execution of each RO transaction is not affected, but only affects the commit time of the RW transaction.
  • In these cases, you should choose to synchronize while reading.
    * The group has more access to write and read less, hope to load balance the read operation, hope to be able to read the latest data when reading from any read member, and do not configure any member in the read load balancing to configure related restrictions Avoid reading stale data.
    * It is hoped that specific transactions in the workload will always read the latest data from the group. For example, whenever sensitive data is updated (such as documents or credentials for similar data), it is desirable to force the latest data to be read.
4.2.2. Configure transaction consistency guarantee
In the "Service Synchronization Point (location)" section in "4.2.1. Understanding Transaction Consistency Assurance", we briefly introduced two concepts: the transaction synchronization point can choose "synchronization on reading" and "synchronization on writing", but this It is a simplified term for easy understanding. The terms used in group replication are: before and after the transaction is executed. This section will introduce the different effects of different consistency level settings on the read-only (RO) and read-write (RW) transactions processed by the group (different consistency level settings correspond to the RO and RW transactions before and after execution. Different combinations).
4.2.2.1. Detailed explanation of consistency level
The transaction consistency level is set by the system variable group_replication_consistency. You can dynamically set a transaction at the session level as needed. You can use these different settings to flexibly provide consistency guarantees for transactions in group replication. The following describes the consistency level in detail based on the list of valid values ​​of the system variable group_replication_consistency.
EVENTUAL: RO and RW transactions will not wait for the completion of the previous transaction application before execution (that is, the transaction is executed directly without waiting for the completion of the backlog transaction application). This is the default value of the group_replication_consistency variable (also the default behavior of group replication before the introduction of this system variable). The RW transaction does not wait for other members to apply the transaction. It means that the transaction in the member that sets the value can be externalized before other members. It also means that in the event of a primary node failover, the new primary node does not need to wait for the backlog of transactions (transactions from the old primary node) to immediately accept new RO and RW transactions, which may cause new RO transactions to read Stale data (because the latest data in the old main node has not been synchronized to the new main node), new RW transactions may be rolled back due to conflicts (conflict authentication detection will find that the new RW transactions may be The backlog of RW transactions conflicts).
  • The flow chart of EVENTUAL conformance level is as follows.

  • A brief description of the EVENTUAL consistency level algorithm combined with the above figure.
    * 1. Transaction T1 (consistency level is EVENTUAL) is executed from group member M1.
    * 2. When transaction T1 is executed to the commit point (commit), the change data of the transaction will be broadcasted to all group members (including the M1 member who initiated transaction T1. For M1, T1 is its local transaction. For M2 and M3, T1 is its remote transaction).
    * 3. After transaction T1 is received by all members of the group, all members will perform conflict authentication detection on it: if there is a conflict, for M1, roll back the T1 transaction, for M2 and M3, discard the reception T1 transaction data packet; if there is no conflict, for M1, the T1 transaction is submitted, and for M2 and M3, the T1 transaction is queued for execution and submission.
    * 4. Transaction T2 (consistency level is EVENTUAL) is executed from group member M3, and then M3 receives the data of T1 transaction. At this time, in M3, T2 transaction does not need to wait for T1 transaction application (commit) to complete You can continue to execute later. If the data of the T2 transaction operation overlaps with the T1 transaction, the data read by T2 may not be the latest, and for the T2 transaction, if there is a conflict with the T1 transaction, there is still a The possibility of rollback.
BEFORE_ON_PRIMARY_FAILOVER: The new RO or RW transaction will be held until the newly elected primary node application completes the backlog of transactions from the old primary node (not applied, similar to being in a waiting state. The new RO or RW transaction will be processed after the application is completed. RO and RW transactions). This ensures that when the main node failover occurs, the client can always query the latest value on the failed main node, thus ensuring consistency. But this means that the new main node's delay in the process of applying the backlog of transactions (here refers to the response delay of the client accessing the new main node) the client needs to handle it by itself. Usually this delay is small, but the actual delay time depends on the size of the backlog.
BEFORE: RW transactions will wait for all previous transactions (backlog transactions) to complete before being applied (applied). RO transaction will wait for all previous transactions (backlog transactions) to complete before being executed. This allows the transaction to ensure that the latest value is read only by sacrificing response delay. In fact, it only ensures the synchronization on the RO transaction. For the RW transaction, it just waits for the backlog of transactions to complete, and does not wait for it to complete the application on all other group members (however, because the RO transaction requires synchronization , RO transactions can synchronize part or even most of the data, so it can reduce the synchronization overhead on RW transactions to a certain extent, that is, this consistency level is suitable for scenarios where more writes and less reads).
  • The flow chart of BEFORE conformance level is as follows.

  • A brief description of the BEFORE consistency level algorithm combined with the above figure.
    * 1. Transaction T1 (consistency level is EVENTUAL) is executed from group member M1.
    * 2. When the transaction T1 is executed to the commit point (commit), the change data of the transaction will be broadcasted to all group members here.
    * 3. After transaction T1 is received by all members of the group, all members will perform conflict authentication detection on it: if there is a conflict, for M1, roll back the T1 transaction, for M2 and M3, discard the reception T1 transaction data packet; if there is no conflict, for M1, the T1 transaction is submitted, and for M2 and M3, the T1 transaction is queued for execution and submission.
    * 4. Transaction T2 (consistency level is BEFORE) is executed from group member M3. Before T2 is executed, a message will be sent to all group members, which provides the global order of T2 transactions (from the above figure we can It is known that the global order of T1 transactions is before T2, because T1 transactions are executed first).
    * 5. When the members of the group receive and process the message in order, M3 will obtain the RECEIVED_TRANSACTION_SET of the group replication application from the message flow (RECEIVED_TRANSACTION_SET is the set of remote transactions that are allowed to submit, regardless of whether these transactions have actually been submitted , They are all included in this collection). This set provides all remote transactions that existed before the T2 transaction. Since the Server has ensured the consistency of local transactions, only remote transactions need to be tracked here. Although M3 has previously sent a message containing the global sequence of T2 transactions to all members of the group, only M3 needs to operate on it, so other group members will discard the message without taking any action.
    * 6. In M3, after the application (submit) has completed all the remote transactions in RECEIVED_TRANSACTION_SET, transaction T2 will start to execute, which can ensure that T2 will not be read or executed like you have for the global order (here the global order is : T1->T2) for outdated data. This kind of waiting only occurs on the Server that has executed a transaction with a consistency level of BEFORE (here is the group member M3 who has executed a T2 transaction with a consistency level of BEFORE), for other group members in the group (here refers to group member M1) And M2) are not affected by this wait.
    * 7. Once the T2 transaction is executed, it will continue to execute according to steps 2 and 3.
    PS: For the consistency level of BEFORE, it covers the consistency guarantee provided by BEFORE_ON_PRIMARY_FAILOVER.
AFTER: The RW transaction will wait for its changes to be applied to all other members. This consistency level has no effect on RO transactions (because RO transactions will not produce data changes). It only ensures that when a RW transaction is committed on a local member, the data changes of the RW transaction will be applied to all other members in the group, so that all subsequent transactions can obtain the latest data on any member (by ensuring that only in RW Synchronization is used in transactions, RW transactions will synchronize all new data written to all other members of the group in real time, which reduces the synchronization overhead on RO transactions. That is to say, this consistency level is more suitable for reads Less writing scenes).
  • The flowchart of AFTER consistency level is as follows.

  • A brief description of the AFTER consistency level algorithm combined with the above figure.
    * 1. Transaction T1 (consistency level AFTER) is executed from group member M1.
    * 2. When the transaction T1 is executed to the commit point (commit), the change data of the transaction will be broadcasted to all group members here.
    * 3. After transaction T1 is received by all members of the group, all members will perform conflict authentication detection on it: if there is a conflict, for M1, roll back the T1 transaction, for M2 and M3, discard the reception If there is no conflict, go to step 4.
    * 4. On other group members (here, M2 and M3), T1 transactions are queued for execution. Once the transaction enters the prepare phase (that is, the data is persisted on the storage engine waiting for the commit instruction), it will be sent to all members Send ACK to confirm.
    * 5. Once all members have received ACK confirmation from all members (for M1, the T1 transaction is initiated by itself, so the prepare state has been implicitly confirmed), at this time, all members will continue to execute T1 The commit operation of the transaction (commit).
    * 6. Transaction T2 (consistency level is EVENTUAL) is executed from group member M3. At this time, because T1 transaction is in the process of committing (not yet committed), T2 transaction will continue to wait for T1 transaction to complete before starting execution, so , You can ensure that any transaction after the T1 transaction will read the data change (the latest data) of T1.
    * 7. Once the transaction T2 starts to execute, it will continue to execute according to the steps 2 and 3 in the "Brief Description of the EVENTUAL Consistency Level Algorithm" (Note that since the consistency level of the T2 transaction is EVENTUAL, T2 The subsequent steps of the transaction will not follow the steps 2 and 3 in "A brief description of the AFTER consistency level algorithm").
  • PS: For the AFTER consistency level, it covers the consistency guarantee provided by BEFORE_ON_PRIMARY_FAILOVER.
BEFORE_AND_AFTER: The highest level of consistency is required. Both RW and RO transactions require data synchronization during execution. RW transactions need to wait for the previous backlog transaction application to complete during execution, and need to wait for their own data changes to be applied on all other group members. RO transactions need to wait for the application of the previous backlog of transactions to complete when executing. This consistency level is suitable for scenarios that require high data read and write consistency.
  • The flow chart of BEFORE_AND_AFTER consistency level is as follows.

  • A brief description of the BEFORE_AND_AFTER consistency level algorithm combined with the above figure.
    * Under the BEFORE_AND_AFTER consistency level, the same transaction will combine the BEFORE and AFTER consistency level algorithms.
  • PS: For the BEFORE_AND_AFTER consistency level, it covers the consistency guarantee provided by BEFORE_ON_PRIMARY_FAILOVER.
Both the consistency levels BEFORE and BEFORE_AND_AFTER can be used for RO and RW transactions. But AFTER consistency level has no effect on RO transactions, because RO transactions will not produce data changes.
4.2.2.2. How to choose the consistency level
Different consistency levels have different applicable scenarios. The following are some applicable scenarios for different consistency levels:
  • Scenario 1: Read more and write less, and when obsolete data is not allowed to be read, it is also required to configure read load balancing. In this case, the consistency level should be selected as AFTER.
  • Scenario 2: Write more and read less, and read stale data is not allowed. In this case, you should choose the consistency level BEFORE.
  • Scenario 3: A specific transaction in the workload (such as updating sensitive data) needs to read the latest data of the group. In this case, the consistency level should be selected as BEFORE.
  • Scenario 4: Read more and write less, and hope that the RW transaction will be synchronized to any other members in the group once committed, so that subsequent RO transactions can read the latest data, and will not cause the RO transaction to read the latest data. Synchronization overhead. In this case, the consistency level should be selected as AFTER.
  • Scenario 5: Read more and write less, and hope that the RW transaction will be synchronized to any other members in the group once committed, and hope that subsequent RW and RO transactions can always read the latest data, and do not want subsequent RO transactions Synchronization overhead occurs when reading the latest data. In this case, the consistency level should be selected as BEFORE_AND_AFTER.
You can choose the scope of the enforced consistency level according to your needs. Note: If the consistency level is set to the global scope, it will have a negative impact on group performance. Therefore, unless necessary, it is recommended to dynamically use the system variable group_replication_consistency to configure the consistency level of the group at the session level as needed.
# 若要在当前会话上强制执行一致性级别,用如下语句设置
mysql> SET @@SESSION.group_replication_consistency= 'BEFORE';

# 要在所有会话上强制执行一致性级别,使用如下语句设置
mysql> SET @@GLOBAL.group_replication_consistency= 'BEFORE';

The scenarios for setting the consistency level on a specific session may be as follows:

  • Scenario 6: In this application scenario, most sentences do not require strong consistency, and only a few sentences (for example: a certain type of sentence) require strong consistency. For example: Regarding the permission modification for accessing a certain database table, in this scenario, we want to ensure that all clients see the correct permissions at all times. You only need to execute the set @@SESSION.group_replication_consistency='AFTER' statement in the session where you modify the database table permissions (any other operations do not need to modify the consistency level, and keep the global value of the system variable group_replication_consistency "EVENTUAL").

  • Scenario 7: On the same system as described in scenario 6, the latest data must be read every day to perform data analysis processing. It is only necessary to execute the set @@SESSION.group_replication_consistency='BEFORE' statement in the session in which the analysis processing is executed.

All in all, unless necessary, there is no need to globally run a higher consistency level for all transactions, especially in scenarios where only some transactions have consistency levels.

Note: All RW transactions are globally sorted in the group. Therefore, once the consistency level of the session level is set to AFTER in the current session, when the RW transaction is executed in the session, it will wait for other member applications to complete the transaction. That is to say, because the RW transaction is globally sorted, and the RW transaction is initiated later, it is actually equivalent to waiting for the completion of all the backlog transactions before the RW transaction, not just the RW transaction.

4.2.2.3. Impact of conformance level
Another way to classify the consistency level is to divide it according to the impact on the group, that is, the impact of the consistency level on other members.
For BEFORE consistency level, in addition to sorting on the transaction flow, it only affects local members, that is, it does not need to coordinate other members, nor does it affect other members' transactions. In other words, the BEFORE consistency level only affects transactions that use that consistency level.
The AFTER and BEFORE_AND_AFTER consistency levels have side effects on concurrent transactions executed on other members. When a transaction with AFTER or BEFORE_AND_AFTER consistency level is executed, even if the subsequent transaction is run at EVENTUAL consistency level, it still needs to wait for AFTER or BEFORE_AND_AFTER. The transaction execution of the consistency level is complete. The same is true for other members. That is, AFTER or BEFORE_AND_AFTER consistency level will affect all ONLINE members.
To further illustrate this point, suppose a group contains three group members: M1, M2, and M3. The following statement is executed on M1:
# 修改一致性级别为AFTER
mysql> SET @@SESSION.group_replication_consistency= AFTER;
# 执行一个INSERT语句
mysql> BEGIN;
mysql> INSERT INTO t1 VALUES (1); # 为了方便看到效果,这里最好是一个大事务
mysql> COMMIT;
Then, when applying the above transaction, execute the following statement on member M2:
# 修改一致性级别为EVENTUAL
mysql> SET SESSION group_replication_consistency= EVENTUAL;
# 执行DML事务,就可以发现M2执行的事务被阻塞,需要等待上述执行先执行完成。需要注意的是,如果在M2执行事务时,M1中的事务还没有被M2收到时,select语句是可以立即执行成功的,但如果M1中的事务被M2收到并进入队列之后,执行select ... for update语句也会被阻塞

BEFORE and AFTER_AND_BEFORE consistency levels can only be used in group members in the ONLINE state. Trying to use them on members in other states (other states include: RECOVERING, OFFLINE, ERROR, UNREACHABLE) will cause an error.

If a non-EVENTUAL consistency level transaction is executed, it continues to wait and has not returned, when the timeout configured by the system variable wait_timeout (8 hours by default) is reached, an ER_GR_HOLD_WAIT_TIMEOUT error message will be thrown.

4.2.2.4. The impact of consistency on the selection
This section describes how the consistency level affects the election of a master (election of a master node) in a master in a single master mode. For example: the group automatically detects failures and adjusts the view of active members, in other words membership configuration. In addition, if the group is deployed in single-primary mode, every time the group membership changes, the status of all group members will be checked in order to detect whether the primary node still exists in the group. If not, select a group member from the list of secondary node members to promote to the new primary node. This process is the process of electing an auxiliary node to be promoted to the main node.
When the system detects a failure and automatically reconfigures, you may hope that once the secondary node is promoted, the data status between the new primary node and the old primary node is the same. In other words, you may hope that when the new main node can provide read and write access to the outside, the new main node has already completed all the backlog transactions, that is, once the application completes the failover to the new main node, it will not Will read or modify stale data records (even if it is temporary).
Starting from MySQL 8.0.14, after the secondary node is promoted to the primary node, you can specify the behavior of the new primary node, and use the new system variable group_replication_consistency to control the consistency level of the new primary node (EVENTUAL by default), if Set to BEFORE_ON_PRIMARY_FAILOVER, before providing external read and write access, it will be applied to complete the backlog of transactions. This ensures that the client can see the latest data after completing the failover to the new primary node. At the same time, the following abnormal phenomena can also be prevented:
  • RO and RW transactions will not read stale data, which can prevent these stale data from being accessed by applications.
  • It will not cause the ridiculous rollback of newly executed RW transactions. This is because new RW transactions that have write conflicts with replication transactions (remote transactions) will be in a pending state at this time, and the backlog needs to be applied before new transactions can be processed. RW affairs.
  • There will be no read deviation in read-write transactions (stale data will not be read), such as:
mysql> BEGIN;
# 假设x=1在t1表中,x=2还在积压事务中,那么,在这里需要等待积压事务应用完成,才能执行查询,以便读取到最新的数据x=2
mysql> SELECT x FROM t1; 
mysql> INSERT x INTO t2;
mysql> COMMIT;

If the above transaction does not use the BEFORE_ON_PRIMARY_FAILOVER consistency level, then the value inserted into the t2 table will result in x=1 instead of x=2 (because of the read deviation), but regardless of whether it is set to the BEFORE_ON_PRIMARY_FAILOVER consistency level. Will not cause write conflicts, but at most only read deviations, resulting in the data written to the t2 table is not the latest.

In order to ensure that all members of the group, no matter who is promoted to the new primary node, will provide the same consistency level, all members of the group should be persistent in the configuration consistency level BEFORE_ON_PRIMARY_FAILOVER (or higher consistency level). This can prevent stale data from being queried after the application failover is completed. The setting statement is as follows:

# 使用set语句将系统变量group_replication_consistency的值持久化为BEFORE_ON_PRIMARY_FAILOVER
root@localhost : (none):57: > SET PERSIST group_replication_consistency='BEFORE_ON_PRIMARY_FAILOVER';
Query OK, 0 rows affected (0.02 sec)

# 上述语句执行完成之后,该系统变量值会被持久化到auto.cnf文件中(该文件是一个JSON格式数组,且其中已经存在了组辅助的一些预设持久化变量,注意:对于使用 SET PERSIST语句持久化系统变量的操作,只会影响到当前成员,其他成员不会进行同步,所以,建议在所有组成员中都执行相同的操作)
[root@node1 ~]# cat /data//mysqldata1/mydata/mysqld-auto.cnf  
{ "Version" : 1 , "mysql_server" : { "group_replication_consistency" : { "Value" : "BEFORE_ON_PRIMARY_FAILOVER" , "Metadata" : { "Timestamp" : 1569841133777625 , "User" : "root" , "Host" : "localhost" } } , "mysql_server_static_options" : { "group
_replication_enforce_update_everywhere_checks" : { "Value" : "OFF" , "Metadata" : { "Timestamp" : 1569402731795015 , "User" : "mysql.session" , "Host" : "localhost" } } , "group_replication_single_primary_mode" : { "Value" : "ON" , "Metadata" : {
"Timestamp" : 1569402731795762 , "User" : "mysql.session" , "Host" : "localhost" } } } } }

Although when using the BEFORE_ON_PRIMARY_FAILOVER consistency level, all write operations will enter the pending state before the application completes all the backlog transactions, but not all read operations are blocked, and some queries that do not modify data are allowed to execute (For example: to view some status tables, which is very useful for troubleshooting and performance monitoring).

  • SHOW statement

  • SET statement

  • DO statement

  • EMPTY statement

  • USE statement

  • Use SELECT statement on performannce_schema and sys database

  • Use SELECT statement on informationn_schema.processlist table

  • Use SELECT statement for user-defined functions that do not specify tables

  • STOP GROUP_REPLICATION statement

  • SHUTDOWN statement

  • RESET PERSIST statement

The transaction cannot always be in an on-hold state. If the time in this state exceeds the value set by the system variable wait_timeout, an ER_GR_HOLD_WAIT_TIMEOUT error message will be returned.

For details on cloning plugins, please refer to the link: https://dev.mysql.com/doc/refman/8.0/en/clone-plugin.html

| About the author

Luo Xiaobo·Database Technology Expert

One of the authors of "A Thousand Golden Recipes-MySQL Performance Optimization Pyramid Rule". Familiar with MySQL architecture, good at overall database tuning, like to specialize in open source technology, and keen on the promotion of open source technology, have done many public database topic sharing online and offline, and published nearly 100 database-related research articles.

Further reading

The full text is over.

Enjoy MySQL 8.0 :)

Teacher Ye's "MySQL Core Optimization" class has been upgraded to MySQL 8.0, scan the code to start the journey of MySQL 8.0 practice

Guess you like

Origin blog.csdn.net/n88Lpo/article/details/108372987