Transaction Consistency Guarantees •No stale reads for read-only and read-write transactions. This prevents stale reads from being externalized to the application by the new primary. •No spurious roll backs for read-write transactions, due to write-write conflicts with replicated read-write transactions still in the backlog waiting to be applied. •No read skew on read-write transactions, such as: • SHOW  statements • SET  statements • DO  statements • EMPTY  statements • USE  statements •using  SELECT  statements against the  performance_schema  and  sys  databases •using  SELECT  statements against the  PROCESSLIST  table from the  infoschema  database • SELECT  statements that do not use tables or user defined functions • STOP GROUP_REPLICATION  statements • SHUTDOWN  statements • RESET PERSIST  statements A transaction cannot be on-hold forever, and if the time held exceeds  wait_timeout  it returns an ER_GR_HOLD_WAIT_TIMEOUT  error. Although all writes are held when using  BEFORE_ON_PRIMARY_FAILOVER  consistency level, not all reads are blocked to ensure that you can still inspect the server while it is applying backlog after a promotion took place. This is useful for debugging, monitoring, observability and troubleshooting. Some queries that do not modify data are allowed, such as the following: This ensures that the members all behave in the same way, and that the configuration is persisted after a restart of the member. To guarantee that the group provides the same consistency level regardless of which member is promoted to primary, all members of the group should have  BEFORE_ON_PRIMARY_FAILOVER  (or a higher consistency level) persisted to their configuration. For example, on each member issue: To summarize, when  group_replication_consistency  is set to  BEFORE_ON_PRIMARY_FAILOVER you are choosing to prioritize consistency over availability, because reads and writes are held whenever a new primary is elected. This is the trade-off you have to consider when configuring your group. It should also be remembered that if flow control is working correctly, backlog should be minimal. Note that the higher consistency levels  BEFORE ,  AFTER , and  BEFORE_AND_AFTER  also include the consistency guarantees provided by  BEFORE_ON_PRIMARY_FAILOVER . This query should not cause a conflict but writes outdated values. > BEGIN; > SELECT x FROM t1; -- x=1 because x=2 is in the backlog; > INSERT x INTO t2; > COMMIT; > SET PERSIST group_replication_consistency=’BEFORE_ON_PRIMARY_FAILOVER’; 3735