content_image/756400.jpg
• --upgrade=MINIMAL  option.  Group Replication cannot be started following a MySQL Server upgrade that uses the MINIMAL option ( --upgrade=MINIMAL ), which does not upgrade system tables on which the replication internals depend. 

• Gap Locks.  Group Replication’s certification process for concurrent transactions does not take into account gap locks, as information about gap locks is not available outside of InnoDB . See Gap Locks for more information. 

<img src='content_image/756400.jpg'>

## Note 

For a group in multi-primary mode, unless you rely on REPEATABLE READ semantics in your applications, we recommend using the READ COMMITTED isolation level with Group Replication. InnoDB does not use gap locks in READ COMMITTED , which aligns the local conflict detection within InnoDB with the distributed conflict detection performed by Group Replication. For a group in single-primary mode, only the primary accepts writes, so the READ COMMITTED isolation level is not important to Group Replication. 

• Table Locks and Named Locks.  The certification process does not take into account table locks (see Section 13.3.6, “LOCK TABLES and UNLOCK TABLES Statements” ) or named locks (see GET_LOCK() ). 

• Binary Log Checksums.  Up to and including MySQL 8.0.20, Group Replication cannot make use of checksums and does not support their presence in the binary log, so you must set binlog_checksum=NONE  when configuring a server instance to become a group member. From MySQL 8.0.21, Group Replication supports checksums, so group members may use the default setting binlog_checksum=CRC32 . The setting for binlog_checksum  does not have to be the same for all members of a group. 

When checksums are available, Group Replication does not use them to verify incoming events on the group_replication_applier  channel, because events are written to that relay log from multiple sources and before they are actually written to the originating server’s binary log, which is when a checksum is generated. Checksums are used to verify the integrity of events on the group_replication_recovery  channel and on any other replication channels on group members. 

• SERIALIZABLE Isolation Level. SERIALIZABLE  isolation level is not supported in multi-primary groups by default. Setting a transaction isolation level to SERIALIZABLE  configures Group Replication to refuse to commit the transaction. 

• Concurrent DDL versus DML Operations.  Concurrent data definition statements and data manipulation statements executing against the same object but on different servers is not supported when using multi-primary mode. During execution of Data Definition Language (DDL) statements on an object, executing concurrent Data Manipulation Language (DML) on the same object but on a different server instance has the risk of conflicting DDL executing on different instances not being detected. 

• Foreign Keys with Cascading Constraints.  Multi-primary mode groups (members all configured with group_replication_single_primary_mode=OFF ) do not support tables with multi-level foreign key dependencies, specifically tables that have defined CASCADING foreign key constraints. This is because foreign key constraints that result in cascading operations executed by a multi-primary mode group can result in undetected conflicts and lead to inconsistent data across the members of the group. Therefore we recommend setting group_replication_enforce_update_everywhere_checks=ON  on server instances used in multi-primary mode groups to avoid undetected conflicts. 

In single-primary mode this is not a problem as it does not allow concurrent writes to multiple members of the group and thus there is no risk of undetected conflicts. 

