#### 18.1.3.1 单主模式

[](<>)[](<>)

在单主模式下（[`group_replication_single_primary_mode=ON`](group-replication-options.html#sysvar_group_replication_single_primary_mode)) 该组有一个设置为读写模式的主服务器。组中的所有其他成员都设置为只读模式（使用[`super_read_only=ON`](server-system-variables.html#sysvar_super_read_only)）。主服务器通常是引导组的第一台服务器。加入组的所有其他服务器了解主服务器并自动设置为只读模式。

在单主模式下，组复制强制只有单个服务器写入组，因此与多主模式相比，一致性检查可以不那么严格，并且不需要额外小心处理 DDL 语句。选项[`group_replication_enforce_update_everywhere_checks`](group-replication-options.html#sysvar_group_replication_enforce_update_everywhere_checks)启用或禁用组的严格一致性检查。在单主模式下部署或将组更改为单主模式时，必须将此系统变量设置为`离开`.

指定为主服务器的成员可以通过以下方式进行更改：

-   如果现有的主节点离开组，无论是自愿还是意外，都会自动选出一个新的主节点。

-   您可以使用指定特定成员作为新的主要成员[`group_replication_set_as_primary()`](group-replication-functions-for-new-primary.html#function_group-replication-set-as-primary)功能。

-   如果您使用[`group_replication_switch_to_single_primary_mode()`](group-replication-functions-for-mode.html#function_group-replication-switch-to-single-primary-mode)函数将在多主模式下运行的组更改为在单主模式下运行，自动选举新的主，或者您可以通过函数指定新的主来指定新的主。

    只有当所有组成员都运行 MySQL 8.0.13 或更高版本时，才能使用这些函数。当自动选举或手动指定新的主服务器时，它会自动设置为读写，其他组成员保持从属，因此是只读的。[图 18.4，“新的初选”](group-replication-single-primary-mode.html#group-replication-primary-election-diagram)显示了这个过程。

[](<>)

**图 18.4 新的初选**

<img alt="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." src="images/single-primary-election.png" height="356" width="899" />

当一个新的主节点被选举或任命时，它可能会积压一些已经应用在旧主节点上但尚未应用在这个服务器上的更改。在这种情况下，在新的主节点赶上旧的主节点之前，读写事务可能会导致冲突并被回滚，而只读事务可能会导致读取过时。Group Replication 的流控制机制可以最大限度地减少快速成员和慢速成员之间的差异，如果它被激活并正确调整，则可以减少发生这种情况的机会。有关流量控制的更多信息，请参阅[第 18.7.2 节，“流量控制”](group-replication-flow-control.html).从 MySQL 8.0.14 开始，您还可以使用[`group_replication_consistency`](group-replication-options.html#sysvar_group_replication_consistency)系统变量来配置组的事务一致性级别以防止此问题。那个设定`BEFORE_ON_PRIMARY_FAILOVER`（或任何更高的一致性级别）在新当选的主服务器上保留新事务，直到应用积压。有关事务一致性的详细信息，请参见[第18.5.3节“交易一致性保证”](group-replication-consistency-guarantees.html). 如果组不使用流控制和事务一致性保证，那么在重新将客户端应用程序重新路由到组之前，等待新主服务器应用其与复制相关的中继日志是一个好做法。

##### 18.1.3.1.1主要选举算法

自动初级成员选举程序包括每个成员查看小组的新观点，订购潜在的新的初级成员，并选择最适合的成员。每个成员都在本地做出自己的决定，遵循MySQL服务器版本中的主要选举算法。因为所有成员都必须做出相同的决定，如果其他组成员运行的是较低的MySQL服务器版本，则成员会调整其主选举算法，以便与组中MySQL服务器版本最低的成员具有相同的行为。

成员在选举初选时考虑的因素如下：

1.  考虑的第一个因素是哪个成员或成员运行的MySQL服务器版本最低。如果所有组成员都运行MySQL 8.0.17或更高版本，则成员首先按照其发行版的补丁版本订购。如果任何成员运行的是MySQL Server 5.7或MySQL 8.0.16或更低版本，则成员首先按其发行版的主要版本排序，并且忽略修补程序版本。

2.  如果有多个成员运行的是最低的MySQL服务器版本，则考虑的第二个因素是这些成员的成员权重，如[`组\u复制\u成员\u权重`](group-replication-options.html#sysvar_group_replication_member_weight)成员上的系统变量。如果组中的任何成员正在运行MySQL Server 5.7，其中该系统变量不可用，则忽略此因素。

    这个[`组\u复制\u成员\u权重`](group-replication-options.html#sysvar_group_replication_member_weight)系统变量指定范围为0-100的数字。所有成员默认为50的权重，因此设置一个低于此值的权重以降低其订购量，并在其上方设置一个权重以增加其订购量。您可以使用此权重函数来优先使用更好的硬件，或确保在主设备的计划维护期间故障转移到特定成员。

3.  如果多个成员运行的是最低的MySQL服务器版本，并且其中多个成员的成员权重最高（或忽略成员权重），则考虑的第三个因素是每个成员的生成服务器UUID的文字顺序，由[`服务器uuid`](replication-options.html#sysvar_server_uuid)系统变量。选择服务器UUID最低的成员作为主要成员。这一因素起到了保证和可预测的平局破坏者的作用，因此，如果任何重要因素都无法确定，那么所有团队成员都会做出相同的决定。

##### 18.1.3.1.2找到主要

[](<>)

要查明在单主模式下部署时，当前哪个服务器是主服务器，请使用`成员角色`中的列[`性能模式。复制组成员`](performance-schema-replication-group-members-table.html)桌子例如：

```
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   |
+-------------------------+-------------+
```

警告

这个`组\复制\主要\成员`状态变量已被弃用，并计划在将来的版本中删除。

或者使用[`组\复制\主要\成员`](server-status-variables.html#statvar_group_replication_primary_member)状态变量。

```
mysql> SHOW STATUS LIKE 'group_replication_primary_member'
```
