MySQL 8.0版本说明
MySQL 8.0源代码文档10bet官方网站
虽然事务同步点部分解释了从概念上有两个同步点可以选择:读或写，这些术语是简化的，在组复制中使用的术语是:之前而且后事务执行。一致性级别可以对组处理的只读(RO)和读写(RW)事务产生不同的影响，如本节所示。
控件在组复制中配置的可能的一致性级别group_replication_consistency变量，以增加事务一致性保证:
最终RO和RW事务在执行之前都不等待前面的事务被应用。这是组复制之前的行为
group_replication_consistency添加了变量。RW事务不等待其他成员应用事务。这意味着事务可以先于其他成员外部化到一个成员。这也意味着，在发生主事务故障转移时，新的主事务可以在应用前一个主事务之前接受新的RO和RW事务。RO事务可能导致过时的值，RW事务可能由于冲突而导致回滚。BEFORE_ON_PRIMARY_FAILOVER新的RO或RW事务与从旧的主系统应用积压的新选择的主系统保持(不应用)，直到应用了任何积压。这确保了在发生主故障转移时(无论有意无意)，客户机总是看到主服务器上的最新值。这保证了一致性，但意味着客户端必须能够在应用backlog时处理延迟。通常这种延迟应该是最小的，但它确实取决于积压的大小。
之前RW事务在应用之前等待所有前面的事务完成。RO事务在执行之前等待所有前面的事务完成。这可以通过只影响事务的延迟来确保该事务读取最新的值。这通过确保仅在RO事务上使用同步，减少了每个RW事务上的同步开销。该一致性级别还包括
BEFORE_ON_PRIMARY_FAILOVER．后RW事务等待，直到它的更改应用到所有其他成员。该值对RO事务没有影响。此模式确保当事务在本地成员上提交时，任何后续事务都会读取写入的值或任何组成员上最近的值。将此模式与主要用于RO操作的组一起使用，以确保所应用的RW事务一旦提交就应用到所有地方。应用程序可以使用这一点来确保后续的读操作获取最新的数据，其中包括最新的写操作。这通过确保仅在RW事务上使用同步来减少每个RO事务上的同步开销。该一致性级别还包括
BEFORE_ON_PRIMARY_FAILOVER．BEFORE_AND_AFTERRW事务等待1)所有前面的事务在应用之前完成，2)直到它的更改应用到其他成员上。RO事务等待所有前面的事务在执行之前完成。该一致性级别还包括
BEFORE_ON_PRIMARY_FAILOVER．
的之前而且BEFORE_AND_AFTER一致性级别可以同时用于RO和RW事务。的后一致性级别对RO事务没有影响，因为它们不会产生更改。
不同的一致性级别为两个dba提供了灵活性，dba可以使用它们设置自己的基础设施;以及那些能够使用最适合应用程序需求的一致性级别的开发人员。以下场景展示了如何根据组的使用情况选择一致性保证级别:
场景1如果您希望负载平衡读操作而不担心读操作过时，那么组写操作要比组读操作少得多。在这种情况下，你应该做出选择
后．场景2您有一个应用了大量写操作的数据集，您希望偶尔进行读操作，而不必担心读取过时的数据。在这种情况下，你应该做出选择
之前．场景3您希望工作负载中的特定事务总是从组中读取最新的数据，因此无论何时更新敏感数据(例如文件或类似数据的凭据)，您都希望强制读取总是最新的值。在这种情况下，你应该做出选择
之前．场景4如果你有一个主要是只读(RO)数据的组，你希望你的读写(RW)事务一旦提交就被应用到所有地方，这样后续的读取就会在最新的数据上完成，包括你最新的写，你不需要在每个RO事务上支付同步，而只在RW事务上支付同步。在这种情况下，你应该做出选择
后．场景5你有一个只读数据为主的组，你希望你的读写(RW)事务总是从组中读取最新的数据，并在提交后应用到所有地方，这样后续的读取都是在最新的数据上完成的，包括你的最新的写，你不需要在每个只读(RO)事务上支付同步，而只在RW事务上。在这种情况下，你应该做出选择
BEFORE_AND_AFTER．
您可以自由选择强制执行一致性级别的范围。这一点很重要，因为如果在全局范围内设置一致性级别，则可能会对团队绩效产生负面影响。因此，可以通过配置组的一致性级别group_replication_consistency不同作用域的系统变量。
要强制当前会话的一致性级别，使用会话作用域:
> set @@session。group_replication_consistency = '前';要在所有会话上强制一致性级别，请使用全局作用域:
> set @@global。group_replication_consistency = '前';在特定会话上设置一致性级别的可能性使您可以利用以下场景:
场景6一个给定的系统处理几个不需要强一致性级别的指令，但有一种指令确实需要强一致性:管理对文档的访问权限;在此场景中，系统更改访问权限，并希望确保所有客户端都看到正确的权限。你只需要
设置@@SESSION。group_replication_consistency = '后'，按照这些指令运行，而让其他指令运行最终设为全局作用域。场景7在场景6中描述的同一个系统上，每天都有一条指令需要执行一些分析处理，因此它需要总是读取最新的数据。要实现这一点，您只需要
设置@@SESSION。group_replication_consistency = '前'在那个特定的指令上。
总而言之，您不需要以特定的一致性级别运行所有事务，特别是当只有一些事务实际需要它时。
注意，所有的读写事务在Group Replication中完全有序，因此即使您将一致性级别设置为后对于当前会话，此事务等待，直到它的更改应用于所有成员，这意味着等待这个事务和所有可能在辅助队列中的前一个事务。在实践中，一致性水平后等待一切直到并包括此事务。
另一种对一致性级别进行分类的方法是根据对组的影响，也就是说，一致性级别对其他成员的影响。
的之前一致性级别除了在事务流上排序之外，只影响本地成员。也就是说，它不需要与其他成员进行协调，也不会对他们的事务产生影响。换句话说，之前只影响使用它的事务。
的后而且BEFORE_AND_AFTER一致性级别确实会对在其他成员上执行的并发事务产生副作用。的事务时，这些一致性级别使其他成员事务等待最终一致性级别开始时，事务与后或BEFORE_AND_AFTER是执行。其他成员等待直到后事务在该成员上提交，即使其他成员的事务具有最终一致性水平。换句话说，后而且BEFORE_AND_AFTER影响所有在线集团成员。
为了进一步说明这一点，想象一个有3个成员的组，M1, M2和M3。在会员M1上客户问题:
> set @@session。group_replication_consistency =后;>开始;INSERT INTO t1 VALUES (1);>提交;然后，在应用上述事务时，在成员M2上一个客户端发出:
SET SESSION group_replication_consistency= finally;在这种情况下，即使第二个事务的一致性级别是最终，因为它开始执行时，第一个事务已经在M2上的提交阶段，第二个事务必须等待第一个事务完成提交，然后才能执行。
您只能使用一致性级别之前，后而且BEFORE_AND_AFTER在在线成员，试图在其他状态的成员上使用它们会导致会话错误。
一致性级别不是的事务最终保持执行直到超时，由wait_timeout值达到，默认为8小时。如果达到超时，则ER_GR_HOLD_WAIT_TIMEOUT抛出错误。
本节描述一个组的一致性级别如何影响已经选举了一个新主单元的单个主单元组。这样的组自动检测故障并调整活动成员的视图，换句话说就是成员配置。此外，如果以单主模式部署组，则每当组的成员关系发生变化时，都会执行检查，以检测组中是否仍有主成员。如果没有，则从辅助成员列表中选择一个新的成员。这通常被称为二次晋升。
考虑到系统自动检测故障并重新配置自身，用户还可能期望，一旦发生升级，新的主服务器在数据方面的状态与旧的主服务器完全相同。换句话说，一旦用户能够对新主服务器进行读写操作，他可能期望在新主服务器上没有应用复制事务的积压。实际上，用户可能期望，一旦他的应用程序故障转移到新的主服务器，就没有机会读取旧数据或写入旧数据记录，即使是暂时的。
当流量控制在一个组上被激活并适当调优时，只有很小的机会在升级后立即从新当选的主要对象中暂时读取过时的数据，因为不应该有积压，或者如果有积压，也应该很小。此外，您可能有一个代理层或中间件层，它们在升级后管理应用程序对主服务器的访问，并在该级别强制执行一致性标准。如果您的组成员使用的是MySQL 8.0.14或更高版本的MySQL，则可以在升级新主服务器时指定它的行为group_replication_consistency变量，它控制新选择的主节点是否同时阻塞读和写，直到backlog完全应用之后，或者它是否以运行MySQL 8.0.13或更早版本的成员的方式运行。如果group_replication_consistency选项设置为BEFORE_ON_PRIMARY_FAILOVER在新选出的有待办事项要应用的主节点上，并且在新主节点仍在应用待办事项时针对该新主节点发布事务，进入的事务将被阻塞，直到完全应用待办事项。防止以下异常:
对只读和读写事务没有过时的读取。这可以防止旧的读取被新的主进程外部化到应用程序。
对于读写事务，不会出现伪回滚，因为它与仍然处于等待应用的backlog中的复制的读写事务存在写-写冲突。
在读写事务上没有读倾斜，例如:
>开始;SELECT x FROM t1;——x=1，因为x=2在backlog中;将x插入t2;>提交;该查询不应该导致冲突，而是写入过时的值。
总结一下，当group_replication_consistency设置为BEFORE_ON_PRIMARY_FAILOVER您选择优先考虑一致性而不是可用性，因为每当选择一个新的主节点时，就会进行读写操作。这是您在配置组时必须考虑的权衡。还应该记住，如果流程控制工作正常，积压应该是最小的。注意，更高的一致性级别之前，后,BEFORE_AND_AFTER还包括提供的一致性保证BEFORE_ON_PRIMARY_FAILOVER．
为了保证组提供相同的一致性级别，无论哪个成员被提升为初级成员，组的所有成员都应该具有相同的一致性级别BEFORE_ON_PRIMARY_FAILOVER(或更高的一致性级别)持久化到它们的配置中。例如，在每个成员问题上:
> SET PERSIST group_replication_consistency='BEFORE_ON_PRIMARY_FAILOVER';这确保所有成员都以相同的方式运行，并且在重新启动成员后保持配置。
尽管在使用时保留所有写操作BEFORE_ON_PRIMARY_FAILOVER一致性级别，不是所有读都被阻塞，以确保在升级发生后，当服务器应用积压时，您仍然可以检查服务器。这对于调试、监视、可观察性和故障排除非常有用。一些不修改数据的查询是允许的，例如:
事务不能永远保持，如果保持的时间超过wait_timeout它返回一个ER_GR_HOLD_WAIT_TIMEOUT错误。