# 18.5.3.1了解交易一致性保证

就分布式一致性保证而言,无论是在正常或故障修复操作中,组复制始终是最终的一致性系统。这意味着,一旦传入流量减慢或停止,所有组成员都具有相同的数据内容。与系统一致性相关的事件可分为手动或故障自动触发的控制操作;以及数据流操作。

对于组复制,可以根据一致性评估的控制操作包括:

# 一致性保证和主故障切换

在单个主组中,在主故障切换的情况下,当辅助组升级为主组时,新的主组可以立即对应用程序通信可用,而不管复制积压有多大,或者可以限制对它的访问,直到应用了积压。

第一种方法是,在主服务器出现故障后,通过选择一个新的主服务器,然后在仍在应用旧主服务器的任何可能积压的数据时,立即允许数据访问,以尽可能短的时间确保稳定的组成员身份。写入一致性得到了保证,但在新的主应用backlog时,读取可以临时检索过时的数据。例如,如果客户机C1编写A=2,其中A=1在旧的主服务器上,当客户端C1重新连接到新的主服务器时,它可能会读取A=1直到新的primary应用其待办事项并在离开组之前赶上旧primary的状态。

对于第二个备选方案,系统在主要故障后确保稳定的组成员身份,并以与第一个备选方案相同的方式选择一个新的主要成员,但在这种情况下,该组会等待,直到新的主要成员应用所有积压工作,然后才允许数据访问。这确保了在如上所述的情况下,当客户端C1重新连接到新的主服务器时,它会读取A=2但是,折衷的办法是,故障切换所需的时间与积压的大小成正比,在正确配置的组中,积压的大小应该很小。

在MySQL 8.0.14之前,无法配置故障切换策略,默认情况下,可用性是最大化的,如第一种方法所述。在成员运行MySQL 8.0.14及更高版本的组中,可以使用组\复制\一致性变量看见一致性对初选的影响.

# 数据流操作

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

# 事务同步点

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

如果数据在写入时同步,则写入会话将等待所有辅助设备写入其数据。组复制在写操作上使用总顺序,因此这意味着等待应用此写操作以及二级队列中所有之前的写操作。因此,在使用此同步点时,写入会话将等待应用所有辅助队列。

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

想象一下以下情况:

  • 为了避免读取陈旧数据,您希望在不部署额外限制的情况下实现读取的负载平衡,组写入比组读取常见得多。

  • 您有一个以只读数据为主的组,您希望读写事务在提交后应用于所有地方,以便后续读取在包含最新写入数据的最新数据上完成。这确保了您不会为每个RO事务支付同步成本,而只为RW事务支付同步成本。

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

    想象一下以下情况:

  • 为了避免读取陈旧数据,您希望在不部署额外限制的情况下实现读取的负载平衡,组写入比组读取更常见。

  • 您希望工作负载中的特定事务始终从组中读取最新数据,例如每当敏感数据更新时(例如文件或类似数据的凭据),并且您希望强制执行读取以检索最新值。

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