在单主组中，如果在从属提升为主时发生主故障转移，则无论复制积压有多大，新的主都可以立即用于应用程序流量，或者可以访问它在应用积压之前受到限制。

使用第一种方法，该组通过选择一个新的主节点，然后在它仍然应用来自旧主节点的任何可能积压的同时立即允许数据访问，从而在主节点失败后花费尽可能少的时间来确保稳定的组成员身份。确保写入一致性，但读取可以在新主应用积压时临时检索陈旧数据。例如，如果客户端 C1 A=2 WHERE A=1在旧主节点发生故障之前写入，当客户端 C1 重新连接到新主节点时，它可能会读取数据A=1，直到新主节点应用其积压并赶上旧主节点离开之前的状态。团体。

对于第二种选择，系统在主要失败后确保稳定的组成员资格，并以与第一种选择相同的方式选择新的主要，但在这种情况下，组然后等待直到新的主要应用所有积压，然后才这样做允许数据访问。这确保在如前所述的情况下，当客户端 C1 重新连接到它读取的新主服务器时 A=2。然而，权衡是故障转移所需的时间与积压的大小成正比，在正确配置的组中积压应该很小。

在 MySQL 8.0.14 之前，无法配置故障转移策略，默认情况下可用性已最大化，如第一种方法中所述。group_replication_consistency 在具有运行 MySQL 8.0.14 及更高版本的成员的组中，您可以使用该变量配置成员在主故障转移期间提供的事务一致性保证级别 。请参阅 一致性对初选的影响。

由于针对组执行的读取和写入，数据流与组一致性保证相关，尤其是当这些操作分布在所有成员时。数据流操作适用于 Group Replication 的两种模式：单主模式和多主模式，但是为了使解释更清楚，它仅限于单主模式。在单个主要组的成员之间拆分传入的读取或写入事务的通常方法是将写入路由到主要组，并将读取平均分配到辅助组。由于该组应该作为一个单独的实体运行，因此可以合理地期望在主节点上的写入在辅助节点上立即可用。尽管 Group Replication 是使用实现 Paxos 算法的 Group Communication System (GCS) 协议编写的，但 Group Replication 的某些部分是异步的，这意味着数据是异步应用于辅助节点的。这意味着客户端 C2 可以写B=2 WHERE B=1在主服务器上，立即连接到辅助设备并读取 B=1. 这是因为次级仍在应用积压，并且尚未应用主应用的事务。

您可以根据您希望跨组同步事务的时间点来配置组的一致性保证。为了帮助您理解这个概念，本节将跨组同步事务的点简化为在读取操作时或在写入操作时。如果数据在读取时同步，则当前客户端会话会等到给定点，即所有先前更新事务都已应用的时间点，然后才能开始执行。使用这种方法，只有这个会话受到影响，所有其他并发数据操作都不会受到影响。

如果数据在写入时同步，则写入会话会一直等待，直到所有辅助节点都写入了它们的数据。Group Replication 在写入时使用总顺序，因此这意味着等待应用次要队列中的此写入和所有先前的写入。因此，当使用此同步点时，写入会话会等待应用所有辅助队列。

任何替代方案都确保在为客户端 C2 描述的情况下，B=2即使立即连接到辅助设备，也始终可以读取。每种选择都有其优点和缺点，这与您的系统工作负载直接相关。以下示例描述了不同类型的工作负载并建议了哪个同步点是合适的。

想象一下以下情况：

在这些情况下，您应该选择同步写入。

想象一下以下情况：

在这些情况下，您应该选择同步读取。