Transaction Consistency Guarantees The  AFTER  and  BEFORE_AND_AFTER  consistency levels do have side-effects on concurrent transactions executed on other members. These consistency levels make the other members transactions wait if transactions with the  EVENTUAL  consistency level start while a transaction with  AFTER  or BEFORE_AND_AFTER  is executing. The other members wait until the  AFTER  transaction is committed on that member, even if the other member’s transactions have the  EVENTUAL  consistency level. In other words,  AFTER  and  BEFORE_AND_AFTER  impact  all ONLINE  group members. To illustrate this further, imagine a group with 3 members, M1, M2 and M3. On member M1 a client issues: Then, while the above transaction is being applied, on member M2 a client issues: > SET SESSION group_replication_consistency= EVENTUAL; In this situation, even though the second transaction’s consistency level is  EVENTUAL , because it starts executing while the first transaction is already in the commit phase on M2, the second transaction has to wait for the first transaction to finish the commit and only then can it execute. You can only use the consistency levels  BEFORE ,  AFTER  and  BEFORE_AND_AFTER  on  ONLINE  members, attempting to use them on members in other states causes a session error. Transactions whose consistency level is not  EVENTUAL  hold execution until a timeout, configured by  wait_timeout  value is reached, which defaults to 8 hours. If the timeout is reached an ER_GR_HOLD_WAIT_TIMEOUT  error is thrown. This section describes how a group’s consistency level impacts on a single-primary group that has elected a new primary. Such a group automatically detects failures and adjusts the view of the members that are active, in other words the membership configuration. Furthermore, if a group is deployed in single-primary mode, whenever the group’s membership changes there is a check performed to detect if there is still a primary member in the group. If there is none, a new one is selected from the list of secondary members. Typically, this is known as the secondary promotion. Given the fact that the system detects failures and reconfigures itself automatically, the user may also expect that once the promotion takes place, the new primary is in the exact state, data-wise, as that of the old one. In other words, the user may expect that there is no backlog of replicated transactions to be applied on the new primary once he is able to read from and write to it. In practical terms, the user may expect that once his application fails-over to the new primary, there would be no chance, even if temporarily, to read old data or write into old data records. When flow control is activated and properly tuned on a group, there is only a small chance of transiently reading stale data from a newly elected primary immediately after the promotion, as there should not be a backlog, or if there is one it should be small. Moreover, you might have a proxy or middleware layers that govern application accesses to the primary after a promotion and enforce the consistency criteria at that level. If your group members are using MySQL 8.0.14 or higher, you can specify the behavior of the new primary once it is promoted using the  group_replication_consistency variable, which controls whether a newly elected primary blocks both reads and writes until after the backlog is fully applied or if it behaves in the manner of members running MySQL 8.0.13 or earlier. If the group_replication_consistency  option was set to  BEFORE_ON_PRIMARY_FAILOVER  on a newly elected primary which has backlog to apply, and transactions are issued against the new primary while it is still applying the backlog, incoming transactions are blocked until the backlog is fully applied. Thus, the following anomalies are prevented: 3734 Impact of Consistency on Primary Election > SET @@SESSION.group_replication_consistency= AFTER; > BEGIN; > INSERT INTO t1 VALUES (1); > COMMIT;