#### 18.8.3.3 组复制在线升级方法

[](<>)

选择以下升级组复制组的方法之一：

##### 滚动组内升级

支持此方法的前提是运行较新版本的服务器不会为组生成工作负载，而其中仍有具有较旧版本的服务器。换句话说，具有较新版本的服务器只能作为辅助服务器加入该组。在这种方法中，只有一个组，每个服务器实例都从组中删除，升级然后重新加入组。

这种方法非常适合单主基团。当组在单主模式下运行时，如果您要求主节点始终保持不变（除非它自己升级），它应该是最后一个升级的成员。除非它运行组中最低的 MySQL 服务器版本，否则主不能保持为主。升级主节点后，您可以使用[`group_replication_set_as_primary()`](group-replication-functions-for-new-primary.html#function_group-replication-set-as-primary)功能重新任命它为主要。如果您不介意哪个成员是主要成员，则可以按任何顺序升级成员。该组在必要时从运行最低 MySQL 服务器版本的成员中选举一个新的主节点，遵循中描述的选举策略[第 18.1.3.1 节，“单主模式”](group-replication-single-primary-mode.html).

对于在多主模式下运行的组，在组内滚动升级期间，主节点的数量会减少，从而导致写入可用性降低。这是因为如果成员在运行高于现有组成员运行的最低版本的 MySQL 服务器版本时加入组，它会自动保持只读模式（[`super_read_only=ON`](server-system-variables.html#sysvar_super_read_only)）。请注意，运行 MySQL 8.0.17 或更高版本的成员在检查时会考虑发布的补丁版本，但运行 MySQL 8.0.16 或更低版本或 MySQL 5.7 的成员仅考虑主要版本。当所有成员都升级到同一版本时，从 MySQL 8.0.17 开始，它们都会自动更改回读写模式。对于早期版本，您必须设置[`super_read_only=OFF`](server-system-variables.html#sysvar_super_read_only)在升级后应作为主要成员的每个成员上手动进行。

有关组中版本兼容性以及在升级过程中如何影响组行为的完整信息，请参阅[第 18.8.1 节，“在组中组合不同的成员版本”](group-replication-online-upgrade-combining-versions.html).

##### 滚动迁移升级

在此方法中，您从组中删除成员，升级它们，然后使用升级的成员创建第二个组。对于在多主模式下运行的组，在此过程中，主节点的数量会减少，从而导致写入可用性降低。这不会影响在单主模式下运行的组。

因为在升级成员时运行旧版本的组在线，所以您需要运行新版本的组来赶上在升级成员时执行的任何事务。因此，新组中的一台服务器被配置为旧组中主服务器的副本。这可确保新组赶上旧组。由于此方法依赖于用于将数据从一个组复制到另一个组的异步复制通道，因此在异步源-副本复制的相同假设和要求下支持它，请参阅[第十七章，*复制*](replication.html).对于在单主模式下运行的组，到旧组的异步复制连接必须将数据发送到新组中的主组，对于多主组，异步复制通道可以连接到任何主组。

该过程是：

-   从运行旧服务器版本的原始组中一一删除成员，请参阅[第 18.8.3.2 节，“升级组复制成员”](group-replication-upgrading-member.html)

-   升级在成员上运行的服务器版本，请参阅[第 2.11 节，“升级 MySQL”](upgrading.html).您可以按照就地或预配方法进行升级。

-   使用升级的成员创建一个新组，请参阅[第十八章，*组复制*](group-replication.html).在这种情况下，您需要在每个成员上配置一个新的组名（因为旧组仍在运行并使用旧名称），引导一个初始升级成员，然后添加剩余的升级成员。

-   在旧组和新组之间建立一个异步复制通道，见[第 17.1.3.4 节，“使用 GTID 设置复制”](replication-gtids-howto.html).将旧的主服务器配置为异步复制源服务器，将新的组成员配置为基于 GTID 的副本。

    在您可以将应用程序重定向到新组之前，您必须确保新组具有合适数量的成员，例如，以便该组可以处理成员的故障。问题`SELECT * FROM performance_schema.replication_group_members`并比较初始组大小和新组大小。等到旧组中的所有数据都传播到新组，然后断开异步复制连接并升级任何丢失的成员。

##### 滚动复制升级

在此方法中，您将创建第二个组，该组由运行较新版本的成员组成，并且旧组中丢失的数据将复制到较新组。这假设您有足够的服务器来同时运行这两个组。由于在这个过程中初选的数量是*不是*减少，对于在多主模式下运行的组，写入可用性没有降低。这使得滚动复制升级非常适合在多主模式下运行的组。这不会影响在单主模式下运行的组。

因为运行旧版本的组在您配置新组中的成员时处于联机状态，所以您需要运行较新版本的组来赶上在配置成员时执行的任何事务。因此，新组中的一台服务器被配置为旧组中主服务器的副本。这可确保新组赶上旧组。由于此方法依赖于用于将数据从一个组复制到另一个组的异步复制通道，因此在异步源-副本复制的相同假设和要求下支持它，请参阅[第十七章，*复制*](replication.html).对于在单主模式下运行的组，到旧组的异步复制连接必须将数据发送到新组中的主组，对于多主组，异步复制通道可以连接到任何主组。

该过程是：

-   部署适当数量的成员，以便运行较新版本的组可以处理成员的故障

-   备份组成员的现有数据

-   使用旧成员的备份来配置新组的成员，请参阅[第 18.8.3.4 节，“组复制升级**mysql备份**”](group-replication-upgrade-with-mysqlbackup.html)对于一种方法。

    笔记

    您必须将备份恢复到与备份相同的 MySQL 版本，然后执行就地升级。有关说明，请参阅[第 2.11 节，“升级 MySQL”](upgrading.html).

-   使用升级的成员创建一个新组，请参阅[第十八章，*组复制*](group-replication.html).在这种情况下，您需要在每个成员上配置一个新的组名（因为旧组仍在运行并使用旧名称），引导一个初始升级成员，然后添加剩余的升级成员。

-   在旧组和新组之间建立一个异步复制通道，见[第 17.1.3.4 节，“使用 GTID 设置复制”](replication-gtids-howto.html).将旧的主服务器配置为异步复制源服务器，将新的组成员配置为基于 GTID 的副本。

    一旦新组中丢失的持续数据小到足以快速传输，您必须将写入操作重定向到新组。等到旧组中的所有数据都传播到新组，然后断开异步复制连接。
