Documentation Home
MySQL 8.3 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 40.8Mb
PDF (A4) - 40.9Mb
Man Pages (TGZ) - 294.0Kb
Man Pages (Zip) - 409.0Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb
Excerpts from this Manual

20.1.3.2 多主模式

在多主模式下(group_replication_single_primary_mode=OFF),没有成员具有特殊角色。任何与其他组成员兼容的成员在加入组时将设置为读写模式,可以处理写事务,即使它们是并发发出的。

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

图 20.5 客户端故障转移

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.

Group Replication 是一个最终一致性系统。这意味着,在入流量减少或停止时,所有组成员都将拥有相同的数据内容。在流量流动时,事务可以在某些成员上外部化,而其他成员尚未这样做,特别是如果某些成员的写入吞吐量较低,导致可能出现陈旧读取。在多主模式下,较慢的成员也可以积累大量待认证和应用的事务,导致冲突和认证失败的风险增加。为了限制这些问题,您可以激活和调整 Group Replication 的流控制机制,以最小化快速和慢速成员之间的差异。有关流控制的更多信息,请参阅 第 20.7.2 节,“流控制”

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

20.1.3.2.1 事务检查

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

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

  • 如果事务对具有级联约束的表执行操作,那么在与组同步时其提交将失败。

这些检查由 group_replication_enforce_update_everywhere_checks 系统变量控制。在多主模式下,系统变量通常应设置为 ON,但可以选择性地将检查停用,方法是将系统变量设置为 OFF。在单主模式下部署时,系统变量必须设置为 OFF

20.1.3.2.2 数据定义语句

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

MySQL 8.3 支持原子数据定义语言(DDL)语句,其中完整的 DDL 语句要么作为单个原子事务提交,要么回滚。DDL 语句,无论是原子的还是其他的,都隐式地结束当前会话中的活动事务,就像您执行了 COMMIT 语句之前执行该语句一样。这意味着 DDL 语句不能在另一个事务中执行,也不能在事务控制语句中执行,例如 START TRANSACTION ... COMMIT,或与同一事务中的其他语句组合。

组复制基于乐观复制范式,其中语句被乐观地执行,然后在必要时回滚。每个服务器在未经组同意的情况下执行语句。因此,在多主模式下复制 DDL 语句时需要更加小心。如果您对同一个对象进行模式更改(使用 DDL)和数据更改(使用 DML),则需要通过同一个服务器处理这些更改,而不是在模式操作完成并在所有地方复制之前。如果不这样做,在操作中断或部分完成时可能会导致数据不一致。如果组部署在单主模式下,这个问题不会出现,因为所有更改都是通过同一个服务器,主服务器。

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

20.1.3.2.3 版本兼容性

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

这些兼容性检查的结果之一在多主模式下尤其重要。如果加入的成员运行的 MySQL 服务器版本高于现有组成员所运行的最低版本,那么它将以只读模式加入组。(在单主模式下运行的组中,新添加的成员默认为只读模式。)运行 MySQL 8.0.17 或更高版本的成员在检查兼容性时将考虑 MySQL 软件的主要版本、次要版本和发布版本。(运行早期版本的成员只考虑主要版本和次要版本。)

在多主模式下运行的组中,组复制自动管理读写和只读模式的成员状态。如果成员离开组,那么现在最低版本的成员将自动设置为读写模式。当您使用 group_replication_switch_to_multi_primary_mode() 函数将组从单主模式更改为多主模式时,组复制将自动将成员设置为正确的模式。成员将自动设置为只读模式,如果它们运行的 MySQL 服务器版本高于组中的最低版本,而运行最低版本的成员将设置为读写模式。

有关组中的版本兼容性和升级过程中的行为的完整信息,请参阅 第 20.8.1 节,“组中的不同成员版本”