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

这种方法非常适合单一主要群体。当组在单主模式下运行时，如果您要求主自始至终保持不变（除了它自己升级时），它应该是最后一个被升级的成员。除非主服务器运行组中最低的 MySQL 服务器版本，否则主服务器不能保持为主服务器。主升级后，您可以使用 group_replication_set_as_primary() 函数将其重新指定为主函数。如果您不介意哪个成员是主要成员，则可以按任何顺序升级成员。根据第 18.1.3.1 节，“单主模式”中描述的选举策略，该组会在必要时从运行最低 MySQL 服务器版本的成员中选出一个新的主 节点。

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

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

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

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

过程是：

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

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

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

过程是：

一旦新组中丢失的正在进行的数据小到可以快速传输，您必须将写入操作重定向到新组。等到旧组中的所有数据都传播到新组，然后删除异步复制连接。