Transaction Consistency Guarantees Any alternative ensures that in the situation described for client C2 would always read  B=2  even if immediately connected to a secondary. Each alternative has its advantages and disadvantages, which are directly related to your system workload. The following examples describe different types of workloads and advise which point of synchronization is appropriate. Imagine the following situations: •you want to load balance your reads without deploying additional restrictions on which server you read from to avoid reading stale data, group writes are much less common than group reads. •you have a group that has a predominantly read-only data, you want read-write transactions to be applied everywhere once they commit, so that subsequent reads are done on up-to-date data that includes the latest write. This ensures that you do not pay the synchronization cost for every RO transaction, but only on RW ones. •you want to load balance your reads without deploying additional restrictions on which server you read from to avoid reading stale data, group writes are much more common than group reads. •you want specific transactions in your workload to always read up-to-date data from the group, for example whenever sensitive data is updated (such as credentials for a file or similar data) and you want to enforce that reads retrieve the most up to date value. In these cases, you should choose to synchronize on writes. Imagine the following situations: In these cases, you should choose to synchronize on reads. 18.5.2.2 Configuring Transaction Consistency Guarantees Although the Transaction Synchronization Points section explains that conceptually there are two synchronization points from which you can choose: on read or on write, these terms were a simplification and the terms used in Group Replication are:  before  and  after  transaction execution. The consistency level can have a different impact on read-only (RO) and read-write (RW) transactions processed by the group as demonstrated in this section. •How to Choose a Consistency Level •Impacts of Consistency Levels •Impact of Consistency on Primary Election The following list shows the possible consistency levels that you can configure in Group Replication using the  group_replication_consistency  variable, in order of increasing transaction consistency guarantee: Both RO and RW transactions do not wait for preceding transactions to be applied before executing. This was the behavior of Group Replication before the  group_replication_consistency  variable was added. A RW transaction does not wait for other members to apply a transaction. This means that a transaction could be externalized on one member before the others. This also means that in the event of a primary failover, the new primary can accept new RO and RW transactions before the previous primary transactions are all applied. RO transactions could result in outdated values, RW transactions could result in a rollback due to conflicts. • EVENTUAL • BEFORE_ON_PRIMARY_FAILOVER 3731