在单主组中，当 secondary 提升为 primary 时，新的 primary 可以选择立即对应用程序流量开放，不管复制 backlog 的大小如何，也可以选择直到 backlog 应用后再开放访问。

使用第一个方法，组件在主节点故障后尽快确保稳定组成员身份，通过选举新的主节点，然后允许数据访问，同时仍然应用可能的 backlog。写入一致性是确保的，但读取可以暂时返回 stale 数据直到新主节点应用 backlog。例如，如果客户端 C1 在老主节点上写入了A=2 WHERE A=1，然后在连接到新的主节点时可能会读取A=1，直到新主节点应用 backlog 并与老主节点的状态保持一致。

使用第二个alternative，系统在主节点故障后确保稳定组成员身份，并选举新的主节点，但是在这个情况下，组件等待新主节点应用所有 backlog，才允许数据访问。这确保了客户端 C1 在连接到新的主节点时读取A=2。然而，这个trade-off 是在故障转移过程中需要的时间与 backlog 的大小成正比，而在正确配置的组件中，backlog 应该很小。

您可以使用group_ replication_ consistency变量来配置成员在主节点故障时提供的事务一致性保证。见Primary Election。

数据流是对组一致性保证的相关因素，因为在组中执行的读取和写入操作，特别是在这些操作分布在所有成员上。数据流操作适用于Group Replication的两个模式：单主(primary)和多主(multi-primary)，但为了使解释更清晰，它将被限制到单主模式。通常情况下，在单主组中的成员之间分配 incoming 读取或写入事务是将写入路由到主节点，并均匀分布读取到从节点上。由于组应该表现为单个实体，因此可以期望在主节点上执行的写入操作立即可用于从节点上。虽然 Group Replication 使用了 Group Communication System（GCS）协议实现 Paxos 算法，但Group Replication 的某些部分是异步的，这意味着数据异步地应用到从节点上。这意味着客户端 C2 可以在主节点上写入 B=2 WHERE B=1，然后立即连接到从节点并读取 B=1。这是因为从节点仍然应用 backlog，而没有应用由主节点应用的事务。

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

如果在写入时数据同步，写入会话将等待所有从属服务器都写入了数据。Group Replication 使用写入的总顺序，因此这意味着写入会话需要等待所有从属服务器队列中的所有写入操作被应用。因此，在使用这个同步点时，写入会话需要等待所有从属服务器队列中的所有写入操作。

任何替代方案都可以确保在客户端C2的情况下总是读取B=2，即使立即连接到从属服务器。每个替代方案都有其优点和缺点，这些优点和缺点直接与您的系统负载相关。以下几个例子描述了不同的工作负载，并建议了合适的同步点。

想象以下情况：

在这种情况下，你应该选择在写入时同步。

想象以下情况：

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