Transaction Consistency Guarantees • Scenario 4  you have a group that has predominantly read-only (RO) data, you want your read-write (RW) transactions to be applied everywhere once they commit, so that subsequent reads are done on up-to-date data that includes your latest writes and you do not pay the synchronization on every RO transaction, but only on RW ones. In this case, you should choose  AFTER . • Scenario 5  you have a group that has predominantly read-only data, you want your read-write (RW) transactions to always read up-to-date data from the group and to be applied everywhere once they commit, so that subsequent reads are done on up-to-date data that includes your latest write and you do not pay the synchronization on every read-only (RO) transaction, but only on RW ones. In this case, you should choose  BEFORE_AND_AFTER . • Scenario 6  A given system handles several instructions that do not require a strong consistency level, but one kind of instruction does require strong consistency: managing access permissions to documents;. In this scenario, the system changes access permissions and it wants to be sure that all clients see the correct permission. You only need to  SET @@SESSION.group_replication_consistency= ‘AFTER’ , on those instructions and leave the other instructions to run with  EVENTUAL  set at the global scope. • Scenario 7  On the same system as described in Scenario 6, every day an instruction needs to do some analytical processing, and as such it requires to always read the most up-to-date data. To achieve this, you only need to  SET @@SESSION.group_replication_consistency= ‘BEFORE’  on that specific instruction. The  BEFORE  consistency level, apart from being ordered on the transaction stream, only impacts on the local member. That is, it does not require coordination with the other members and does not have repercussions on their transactions. In other words,  BEFORE  only impacts the transactions on which it is used. Another way to classify the consistency levels is in terms of impact on the group, that is, the repercussions that the consistency levels have on the other members. Note that all read-write transactions are totally ordered in Group Replication, so even when you set the consistency level to  AFTER  for the current session this transaction waits until its changes are applied on all members, which means waiting for this and all preceding transactions that could be in the secondaries’ queues. In practice, the consistency level  AFTER  waits for everything until and including this transaction. To summarize, you do not need to run all transactions with a specific consistency level, especially if only some transactions actually require it. The possibility of setting the consistency level on specific sessions enables you to take advantage of scenarios such as: You have the freedom to choose the scope at which the consistency level is enforced. This is important because consistency levels could have a negative impact on group performance if you set them at a global scope. Therefore you can configure the consistency level of a group by using the group_replication_consistency  system variable at different scopes. To enforce the consistency level on the current session, use the session scope: To enforce the consistency level on all sessions, use the global scope: Impacts of Consistency Levels > SET @@GLOBAL.group_replication_consistency= ’BEFORE’; > SET @@SESSION.group_replication_consistency= ’BEFORE’; 3733