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.1 单主模式

在单主模式(group_ replication_single_primary_mode=ON)中,组只有一个主要服务器,该服务器设置为读写模式。组中的所有其他成员都设置为只读模式(使用super_read_only=ON)。主要服务器通常是组的第一个服务器来引导组。组中的所有其他服务器都学习到主要服务器,并自动设置为只读模式。

在单主模式下,Group Replication 强制确保只有单个服务器对组进行写入,因此与多主模式相比,consistency 检查可以更少严格,DDL 语句不需要特殊处理。选项group_replication_enforce_update_everywhere_checks启用或禁用组的严格一致性检查。在部署到单主模式或将组更改为单主模式时,这个系统变量必须设置为OFF

可以在以下方式下更改主要服务器的身份:

  • 如果现有主要服务器离开组,无论是自愿或意外,新的主要服务器将自动被选举。

  • 您也可以使用group_replication_set_as_primary()函数指定特定的成员为新主要服务器。

  • 如果使用group_ replication_switch_to_single_primary_mode()函数将运行在多主模式下的组更改为单主模式,新的主服务器将自动被选举或可以手动指定。

当新的主服务器自动被选举或手动指定时,它将自动设置为读写模式,而其他组成员将保持为次要服务器,且为只读。 图20.4,“新主选举”展示了这个过程。

图20.4 新主选举

Five server instances, S1, S2, S3, S4, and S5, are deployed as an interconnected group. Server S1 is the primary. Write clients are communicating with server S1, and a read client is communicating with server S4. Server S1 then fails, breaking communication with the write clients. Server S2 then takes over as the new primary, and the write clients now communicate with server S2.

当新的主服务器被选举或任命时,它可能会有一个 backlog,包含在旧主服务器上已经应用的更改,但还没有在这个服务器上应用。这种情况下,直到新主服务器赶上旧主服务器,读写事务可能会导致冲突并回滚,读-only 事务可能会导致 stale reads。Group Replication 的流量控制机制,可以减少快速和慢速成员之间的差异,从而降低这个问题的可能性。如果它被激活并正确地调试,可以查看第20.7.2节,“流量控制”获取更多信息。您还可以使用group_ replication_consistency系统变量来配置组的事务一致性级别,以防止这个问题。将其设置为BEFORE_ON_PRIMARY_FAILOVER或更高的一致性级别,可以在新选举的主服务器上保持新的事务,直到 backlog 已经被应用。(在 MySQL 8.4 中,这是默认值。)

关于事务一致性,请查看第20.5.3节,“事务一致性保证”。如果流量控制和事务一致性保证不用于组,它是一个良好的实践,等待新主服务器应用其 replication 相关的 relay 日志,然后重新路由客户端应用程序到它。

自动主节点选举过程中,每个成员都会查看组的新视图,按照潜在的新主节点成员顺序,并选择最适合的成员。每个成员都将其决策本地化,遵循 MySQL Server 发行版本中的主节点选举算法。由于所有成员都必须达成同一决策,因此成员会根据其他组成员运行的 MySQL Server 版本调整其主节点选举算法,以便与组中最低 MySQL Server 版本的成员具有相同的行为。

成员在选择主节点时考虑的因素顺序如下:

  1. 首先考虑的是哪个成员或成员运行的 MySQL Server 版本是最低。如果所有组成员都运行 MySQL 8.0.17 或更高版本,成员将首先按照其发布的补丁版本排序。 (如果有成员运行 MySQL 8.0.16 或更早版本——不建议与运行 MySQL 8.4 的成员一起使用——这些成员将首先按照其主要版本排序,并忽略补丁版本。)

  2. 如果多个成员都运行最低的 MySQL Server 版本,那么第二个因素是每个那些成员的成员权重,根据group_replication_member_weight系统变量在成员上指定。

    系统变量group_replication_member_weight指定一个0-100之间的数字。所有成员默认权重为50,因此将权重设置低于此值以降低其顺序,或者将权重设置高于此值以提高其顺序。你可以使用这个加权函数来优先使用更好的硬件或在主服务器计划维护期间确保故障转移到特定成员。

  3. 如果有多个成员正在运行最低的MySQL Server版本,并且其中有一些成员具有最高的成员权重(或者成员权重被忽略),那么第三个考虑因素是每个成员生成的服务器UUID的字母顺序,按照系统变量server_uuid指定。选择最低的服务器UUID作为主服务器。这一因素起到确定和可预测的平局解决方案,使得所有组成员都能达成同样的决策,如果不能通过重要因素来确定。

在单主模式下部署时,想要知道当前哪个服务器是主服务器,可以使用MEMBER_ROLE列在表performance_schema.replication_group_members中。例如:

mysql> SELECT MEMBER_HOST, MEMBER_ROLE FROM performance_schema.replication_group_members;
+-------------------------+-------------+
| MEMBER_HOST             | MEMBER_ROLE |
+-------------------------+-------------+
| remote1.example.com     | PRIMARY     |
| remote2.example.com     | SECONDARY   |
| remote3.example.com     | SECONDARY   |
+-------------------------+-------------+