Documentation Home
MySQL 8.4 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 39.8Mb
PDF (A4) - 39.9Mb
Man Pages (TGZ) - 257.9Kb
Man Pages (Zip) - 364.9Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb


20.1.3.2 多主模式

在多主模式(group_ replication_single_primary_mode=OFF)中,没有成员拥有特殊角色。加入组的任何兼容成员都将被设置为读写模式,可以处理写事务,即使这些事务是并发提交的。

如果某个成员停止接受写事务,例如在服务器意外退出事件中,连接到它的客户端可以被重定向或故障转移到任何其他成员上,该成员处于读写模式。Group Replication 不负责客户端故障转移,因此您需要使用中间件框架,如MySQL Router 8.4、代理、连接器或应用程序本身来安排此操作。Figure 20.5,“客户端故障转移”展示了如果某个成员离开组时,客户端如何重新连接到备用组成员。

Figure 20.5 Client Failover

Five server instances, S1, S2, S3, S4, and S5, are deployed as an interconnected group. All of the servers are primaries. Write clients are communicating with servers S1 and S2, and a read client is communicating with server S4. Server S1 then fails, breaking communication with its write client. This client reconnects to server S3.

组播复制是一个最终一致性系统。这意味着,当 incoming流量减慢或停止时,所有组成员都将拥有相同的数据内容。虽然流量流动时,事务可以在一些成员上执行,而其他成员还没有执行,这尤其是当一些成员具有较低的写入吞吐量时,可能会出现过期读取的问题。在多主模式下,速度较慢的成员也可能积累大量的事务以便证实和应用,从而增加冲突和证实失败的风险。为了限制这些问题,您可以激活和调整组播复制的流量控制机制,以最小化快速和慢速成员之间的差异。有关流量控制的更多信息,请见第20.7.2节,“流量控制”

如果您想要在组中为每个事务保证交易一致性,可以使用group_replication_consistency系统变量。您可以选择合适的设置,以适应组的工作负载和数据读写优先级,考虑到提高一致性的同步性能影响。您也可以为单个会话设置系统变量,以保护特别敏感的事务。有关交易一致性更多信息,请见第20.5.3节,“交易一致性保证”

在多主模式下部署组播时,事务将被检查以确保它们与该模式兼容。以下是Group Replication在多主模式下执行的严格一致性检查:

  • 如果事务在SERIALIZABLE隔离级别下执行,那么在同步自身与组时,它的提交将失败。

  • 如果事务对具有外键和级联约束的表进行操作,那么在同步自身与组时,它的提交将失败。

这些检查由group_ replication_enforce_update_everywhere_checks系统变量控制。在多主模式下,系统变量通常应该设置为ON,但可以选择性地将其设置为OFF以禁用检查。在单主模式下,系统变量必须设置为OFF

20.1.3.2.2 数据定义语句

在多主模式下的Group Replication拓扑结构中,需要小心地执行数据定义语句,也称为数据定义语言(DDL)。

MySQL 8.4 支持原子数据定义语言(DDL)语句,整个 DDL 语句将作为单个原子事务提交或回滚。无论是原子式还是非原子式的 DDL 语句,在当前会话中都隐式地结束任何活动的事务,就像你在执行语句之前已经做了一个COMMIT一样。这意味着 DDL 语句不能在另一个事务中执行,也不能与其他语句组合在同一个事务中。

Group Replication 基于乐观复制范式,语句被乐观地执行,然后如果必要就回滚。每个服务器都执行不需要首先获取群组同意。因此,在多主模式下复制 DDL 语句时需要更多的关注。如果你对同一个对象进行架构更改(使用 DDL)和数据更改(使用 DML),这些更改需要在架构操作还没有完成且已被复制到所有服务器之前通过同一个服务器处理。否则,在操作中断或只部分完成时可能会导致数据不一致。如果群组在单主模式下部署,这个问题不会出现,因为所有更改都通过同一个服务器,主要服务器,进行。

关于原子 DDL 支持的更多信息,请见第15.1.1节,“原子数据定义语句支持”

为了获得最佳的兼容性和性能,组中的所有成员都应该运行相同版本的 MySQL 服务器,因此也应该运行相同版本的 Group Replication。在多主模式中,这点尤其重要,因为组中的所有成员通常都会连接到组中以读写模式。如果组中包含运行多个 MySQL 服务器版本的成员,那么有一些成员可能与其他成员不兼容,因为它们支持其他成员不支持的函数,或者缺少其他成员拥有的函数。为了防止这种情况,新的成员加入时(包括曾经升级并重新启动的成员),该成员将对组中的其他成员进行兼容性检查。

这些兼容性检查的结果在多主模式中尤其重要。如果加入的成员运行的 MySQL 服务器版本高于组中现有成员运行的最低版本,那么它将加入组,但保持只读模式。(在单主模式中的组中,新添加的成员默认情况下都是只读的。)运行 MySQL 8.0.17 或更高版本的成员会考虑 MySQL 软件的 major.minor.release 版本(因此,也是 Group Replication 插件的版本),进行兼容性检查。运行早期版本的成员则只考虑 major.minor 版本。

在多主模式下运行的组中,成员使用不同的MySQL Server版本时,Group Replication自动管理读写和只读状态。如果一个成员离开组,运行最新版本的成员将被自动设置为只读模式。将单主模式下的组更改为多主模式时,使用group_replication_switch_to_multi_primary_mode()函数,Group Replication将自动设置成员到正确的模式。运行高版本MySQL Server的成员将被自动设置为只读模式,而运行最低版本的成员将被设置为读写模式。

关于组中的版本兼容性和升级过程中组行为的详细信息,请见第20.8.1节,“组中的不同成员版本”