文档首页
MySQL 9.0 参考手册
相关文档 下载此手册
PDF (US Ltr) - 40.0Mb
PDF (A4) - 40.1Mb
手册页 (TGZ) - 258.2Kb
手册页 (Zip) - 365.3Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb


MySQL 9.0 参考手册  /  ...  /  多主模式

20.1.3.2 多主模式

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

如果成员停止接受写事务,例如,在意外服务器退出时,连接到它的客户端可以被重定向或故障转移到任何其他处于读写模式的成员。组复制本身不处理客户端侧的故障转移,因此您需要使用中间件框架(如 MySQL 路由器 9.0、代理、连接器或应用程序本身)来安排此操作。 图 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.

组复制是一种最终一致性系统。这意味着一旦传入流量减慢或停止,所有组成员都将具有相同的数据内容。在流量流动的过程中,事务可以在某些成员上比其他成员更早地外部化,尤其是在某些成员的写吞吐量低于其他成员的情况下,从而有可能出现陈旧读取。在多主模式下,速度较慢的成员也会积压过多的待认证和应用事务,从而导致更大的冲突和认证失败风险。为了限制这些问题,您可以激活和调整组复制的流量控制机制,以最大程度地减少快速成员和慢速成员之间的差异。有关流量控制的更多信息,请参阅 第 20.7.2 节,“流量控制”

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

20.1.3.2.1 事务检查

当组以多主模式部署时,将检查事务以确保它们与该模式兼容。当组复制以多主模式部署时,将进行以下严格的一致性检查

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

  • 如果事务针对具有级联约束的外键的表执行,则在与组同步时,其提交将失败。

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

20.1.3.2.2 数据定义语句

在以多主模式部署的组复制拓扑中,在执行数据定义语句(也称为数据定义语言 (DDL))时,需要格外小心。

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

组复制基于乐观复制范式,其中语句被乐观地执行,并在必要时回滚。每个服务器都在未先获得组协议的情况下执行。因此,在多主模式下复制 DDL 语句时需要更加小心。如果您对同一对象的架构进行更改(使用 DDL)以及对该对象包含的数据进行更改(使用 DML),则这些更改需要通过同一服务器来处理,而架构操作尚未完成且尚未在任何地方复制。如果操作被中断或仅部分完成,则未能做到这一点会导致数据不一致。如果组以单主模式部署,则不会出现此问题,因为所有更改都通过同一服务器(主节点)执行。

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

20.1.3.2.3 版本兼容性

为了获得最佳的兼容性和性能,组中的所有成员都应该运行相同版本的 MySQL Server 和 Group Replication。在多主模式下,这一点更为重要,因为所有成员通常都以读写模式加入组。如果组中包含运行多个 MySQL Server 版本的成员,则可能会导致某些成员与其他成员不兼容,因为它们支持其他成员不支持的功能,或者缺少其他成员拥有的功能。为了防止这种情况,当新成员加入(包括已升级和重新启动的旧成员)时,成员会对组中其他成员进行兼容性检查。

这些兼容性检查的结果在多主模式下尤其重要。如果加入的成员运行的 MySQL Server 版本高于现有组成员运行的最低版本,则它将加入组,但保持只读模式。(在以单主模式运行的组中,新添加的成员默认情况下始终处于只读模式。)运行 MySQL 8.0.17 或更高版本的成员在检查其兼容性时会考虑 MySQL 软件(以及 Group Replication 插件)的主版本.次版本.发布版本。运行早期版本的成员只考虑主版本.次版本。

在以多主模式运行且成员使用不同 MySQL Server 版本的组中,Group Replication 会自动管理运行 MySQL 8.0.17 或更高版本的成员的读写和只读状态。如果成员离开组,则运行当前最低版本的成员会自动设置为读写模式。当您使用 group_replication_switch_to_multi_primary_mode() 函数将以单主模式运行的组更改为以多主模式运行时,Group Replication 会自动将成员设置为正确的模式。如果成员运行的 MySQL 服务器版本高于组中存在的最低版本,则会自动将成员置于只读模式,而运行最低版本的成员则会置于读写模式。

有关组中版本兼容性的完整信息以及这如何在升级过程中影响组的行为,请参阅 第 20.8.1 节,“在组中组合不同的成员版本”