概念描述
MGR 相对于半同步复制，在 relay log 前增加了冲突检查协调，但是 binlog 回放仍然可能延时，也就是跟我们熟悉的半同步复制存在 SQL 线程的回放延迟情况类似。当然关于 SQL 线程回放慢的原因，跟半同步也类似，比如大事务。所以MGR并不是全同步方案，关于如何处理一致性读写的问题，MySQL 在 8.0.14 版本中加入了 “读写一致性” 特性，并引入了参数：group_replication_consistency，下面将对读写一致性的相关参数及不同应用场景进行详细说明。
| 参数值 | |
|---|---|
| 命令行格式 | group-replication-consistency=value |
| 介绍 | 8.0.14 |
| 系统变量 | group_replication_consistency |
| 范围 | 全局、会话 |
| 动态的 | 是 |
| 类型 | 枚举 |
| 默认值 | EVENTUAL |
| 有效值 | EVENTUAL、BEFORE_ON_PRIMARY_FAILOVER、BEFORE、AFTER、BEFORE_AND_AFTER |
当组复制运行时，可以更改此系统变量的值。 group_replication_consistency 是服务器系统变量而不是组复制插件特定的变量，因此不需要重新启动组复制即可使更改生效。更改系统变量的会话值会立即生效，更改全局值会对更改后启动的新会话生效。需要具有该 GROUP_REPLICATION_ADMIN 权限才能更改此系统变量的全局设置。
测试验证
- EVENTUAL 默认值(最终一致性，性能最好)，开启事务（T2），事务执行前不会等待先序事务（T1）的回放完成，也不会影响后序事务等待该事务回放完成。
- BEFORE（本地强一致性，性能约下降10%）开启事务（T2），在开始前首先要等待先序事务（T1）的回放完成，确保此事务将在最新的数据上执行。
- AFTER（全局强一致性，性能极差），开启事务（T1），只有等该事务回放完成。其他后序事务（T2）才开始执行，这样所有后序事务都会读取包含其更改的数据库状态，而不管它们在哪个成员上执行。
- BEFORE_AND_AFTER（结合 BEOFRE 和 AFTER 的特性，性能极差）开启事务（T2），需要等待前序事务的回放完成（T1）；同时后序事务（T3）等待该事务的回放完成，这可以保证此事务在最新的数据快照上执行，并且一旦事务完成，所有后续任何不管在哪个成员上执行的事务都会读取包含其更改的数据状态，同步的开销较高。
- BEFORE_ON_PRIMARY_FAILOVER（与积压量成正比），在发生切换时，连到新主的事务会被阻塞，等待先序提交的事务回放完成；这样确保在故障切换时客户端都能读取到主服务器上的最新数据，保证了一致性，但意味着客户端必须能够处理应用积压事件时的延迟。通常这种延迟应该是最小的，所以还是取决于积压的大小。
知识总结
一、 MGR 读写一致性的优缺点
官方引入的 MGR 读写一致性既有它自身的天然优势，也不可避免的存在相应的不足，其优缺点如下：
优点：MGR 配合中间件，比如读写分离功能的中间件，在 MGR 单主模式下，可以根据业务场景进行读写分离，不用担心会产生延迟，充分利用了 MGR 主节点以外的节点。
缺点：使用读写一致性会对性能有极大影响，尤其是网络环境不稳定的场景下。在实际应用中需要大家因地制宜，根据实际情况选择最适配的方案。
二、 MGR 读写一致性的方案
针对不同应用场景应当如何选择MGR读写一致性的相关方式，官方提供了几个参数以及与其相对应的应用场景：
AFTER
适用场景1：写少读多的场景进行读写分离，担心读取到过期事务，可选择 AFTER。
适用场景2：只读为主的集群，有RW的事务需要保证提交的事务能被其他后序事务读到最新读数据，可选择 AFTER。
BEFORE
适用场景1：应用大量写入数据，偶尔进行读取一致性数据，应当选择 BEFORE。
适用场景2：有特定事务需要读写一致性，以便对敏感数据操作时，始终读取最新的数据；应当选 BEFORE。
BEFORE_AND_AFTER
适用场景：有一个读为主的集群，有RW的事务既要保证读到最新的数据，又要保证这个事务提交后，被其他后序事务读到；在这种情况下可选择 BEFORE_AND_AFTER。
