Transaction Checks Data Definition Statements 3696 Multi-Primary and Single-Primary Modes Figure 18.5, “Client Failover”  shows how clients can reconnect to an alternative group member if a member leaves the group. Figure 18.5 Client Failover Group Replication is an eventual consistency system. This means that as soon as the incoming traffic slows down or stops, all group members have the same data content. While traffic is flowing, transactions can be externalized on some members before the others, especially if some members have less write throughput than others, creating the possibility of stale reads. In multi-primary mode, slower members can also build up an excessive backlog of transactions to certify and apply, leading to a greater risk of conflicts and certification failure. To limit these issues, you can activate and tune Group Replication’s flow control mechanism to minimize the difference between fast and slow members. For more information on flow control, see Section 18.7.2, “Flow Control” . From MySQL 8.0.14, if you want to have a transaction consistency guarantee for every transaction in the group, you can do this using the  group_replication_consistency  system variable. You can choose a setting that suits the workload of your group and your priorities for data reads and writes, taking into account the performance impact of the synchronization required to increase consistency. You can also set the system variable for individual sessions to protect particularly concurrency-sensitive transactions. For more information on transaction consistency, see Section 18.5.2, “Transaction Consistency Guarantees” . When a group is deployed in multi-primary mode, transactions are checked to ensure they are compatible with the mode. The following strict consistency checks are made when Group Replication is deployed in multi-primary mode: The checks are controlled by the  group_replication_enforce_update_everywhere_checks system variable. In multi-primary mode, the system variable should normally be set to  ON , but the checks can optionally be deactivated by setting the system variable to  OFF . When deploying in single-primary mode, the system variable must be set to  OFF . •If a transaction executes against a table that has foreign keys with cascading constraints, then its commit fails when synchronizing itself with the group. •If a transaction is executed under the SERIALIZABLE isolation level, then its commit fails when synchronizing itself with the group.