MySQL 9.0 发行说明
在分布式一致性保证方面，无论是正常操作还是故障修复操作，组复制一直都是最终一致性系统。这意味着，一旦传入流量减慢或停止，所有组成员都将具有相同的数据内容。与系统一致性相关的事件可以分为控制操作（手动或由故障自动触发）和数据流操作。
对于组复制，可以根据一致性评估的控制操作包括
成员加入或离开，这由组复制的 第 20.5.4 节，“分布式恢复” 和写入保护涵盖。
网络故障，这由隔离模式涵盖。
在单主组中，主服务器故障转移，这也可以是
group_replication_set_as_primary()触发的操作。
在单主组中，如果发生主服务器故障转移，将辅助服务器提升为主服务器，则新主服务器可以立即对应用程序流量可用，而不管复制延迟有多大，或者可以选择限制对它的访问，直到应用延迟。
使用第一种方法，该组将在主服务器故障后尽可能快地确保稳定的组成员资格，方法是选举新的主服务器，然后立即允许数据访问，同时仍然应用可能来自旧主服务器的任何延迟。写入一致性得到保证，但读取可能会暂时检索到旧数据，同时新主服务器应用延迟。例如，如果客户端 C1 在旧主服务器故障之前写入 A=2 WHERE A=1，当客户端 C1 重新连接到新主服务器时，它可能会在新的主服务器应用其延迟并赶上旧主服务器离开组之前的状态之前读取 A=1。
使用第二种方法，该系统将在主服务器故障后以与第一种方法相同的方式确保稳定的组成员资格并选举新的主服务器，但在此情况下，该组将等待直到新主服务器应用所有延迟，然后才允许数据访问。这确保了在前面描述的情况下，当客户端 C1 重新连接到新主服务器时，它会读取 A=2。但是，权衡的是，故障转移所需的时间将与延迟的大小成正比，在正确配置的组上，延迟应该很小。
您可以使用 group_replication_consistency 变量配置主服务器故障转移期间成员提供的事务一致性保证级别。请参阅 一致性对主服务器选举的影响。
数据流与组一致性保证相关，因为针对组执行的读取和写入，特别是在这些操作分布在所有成员之间的情况下。数据流操作适用于两种组复制模式：单主模式和多主模式，但是为了使此解释更清晰，它被限制在单主模式。在单主组的成员之间拆分传入读取或写入事务的常用方法是将写入路由到主服务器，并将读取均匀分布到辅助服务器。由于该组应该表现为单个实体，因此可以合理地期望主服务器上的写入立即在辅助服务器上可用。虽然组复制是使用实现 Paxos 算法的组通信系统 (GCS) 协议编写的，但组复制的某些部分是异步的，这意味着数据是异步应用到辅助服务器的。这意味着客户端 C2 可以将 B=2 WHERE B=1 写入主服务器，立即连接到辅助服务器并读取 B=1。这是因为辅助服务器仍在应用延迟，并且尚未应用由主服务器应用的事务。
您根据要同步组中事务的点来配置组的一致性保证。为了帮助您理解该概念，本节简化了在组中同步事务的点，这些点是在读取操作时或写入操作时。如果数据在读取时同步，则当前客户端会话将等待直到给定的点，即所有先前更新事务都已应用的点，然后才能开始执行。使用这种方法，只有此会话受到影响，所有其他并发数据操作都不会受到影响。
如果数据在写入时同步，则写入会话将等待直到所有辅助服务器都写入其数据。组复制对写入使用总顺序，因此这意味着等待此写入和辅助服务器队列中的所有先前写入应用。因此，当使用此同步点时，写入会话将等待所有辅助服务器队列应用。
任何替代方案都确保在为客户端 C2 描述的情况下，即使立即连接到辅助服务器，也会始终读取 B=2。每种替代方案都有其优缺点，这些优缺点与您的系统工作负载直接相关。以下示例描述了不同类型的工作负载，并建议哪种同步点适合。
想象以下情况
您希望负载均衡读取，而无需对从哪个服务器读取进行额外限制，以避免读取旧数据，组写入比组读取少得多。
如果您有一个主要包含只读数据的组，您希望读写事务在提交后在所有地方应用，以便后续读取在包含最新写入的最新数据上进行。这样可以确保您不会为每个 RO 事务支付同步成本，而只为 RW 事务支付同步成本。
在这些情况下，您应该选择在写入时同步。
想象以下情况
您希望在不部署对从哪个服务器读取的额外限制的情况下平衡读取负载，以避免读取陈旧数据，组写入比组读取更常见。
您希望工作负载中的特定事务始终从组中读取最新数据，例如，无论何时更新敏感数据（如文件凭据或类似数据），并且您希望强制读取检索最新值。
在这些情况下，您应该选择在读取时同步。