这个方法在以下情况下支持：服务器运行 newer 版本时，不生成工作负载到组中，同时组中仍有服务器运行 older 版本。在这个方法中，只有一个组，每个服务器实例从组中被移除，升级后重新加入组。

这个方法非常适合单主组。单主组操作时，如果您需要保持主服务器不变（除了在它自己升级时），那么最后一个成员应该是升级的。主服务器不能保持为主服务器除非它运行组中最低版本的 MySQL 服务器。在主服务器升级后，您可以使用group_ replication_set_as_primary()函数重新指定它为主服务器。如果您不介意哪个成员是主服务器，成员可以升级任意顺序。组在必要时从运行最低 MySQL 服务器版本的成员中选举新的主服务器，遵循第20.1.3.1节，“单主模式”中描述的选举策略。

在多主模式下运行的组中，rolling in-group 升级过程中，主节点数量减少，从而导致写入可用性降低。这是因为当一个成员加入组时，如果它正在运行比组中的其他成员更高版本的 MySQL 服务器，它将自动保持只读模式（super_read_only=ON）。

关于组中的版本兼容性和升级过程中组行为的详细信息，请见第20.8.1节，“组中的不同成员版本”。

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

由于您正在升级成员，而组运行的版本较旧，因此需要组运行的新版本来追踪在升级成员时执行的事务。因此，在新组中配置一个服务器作为来自旧组的主服务器的副本。这确保了新组可以追踪旧组。由于这个方法依赖于异步复制通道，该通道用于从一个组到另一个组复制数据，因此它受异步源-副本复制的相同假设和要求，见第19章, 复制。对于单主模式的组，异步复制连接到旧组必须将数据发送到新组中的主服务器，而对于多主模式的组，异步复制通道可以连接到任何主服务器。

过程如下：

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

在这个方法中，您创建一个第二组，其中包含运行 newer 版本的成员，并将老组中的缺失数据复制到新组。这假设您有足够的服务器来同时运行两个组。由于在这个过程中， primaries 的数量不减少，因此对于操作在多主模式下的组，没有写入可用性降低。这使得rolling duplication upgrade非常适合操作在多主模式下的组。这对操作在单主模式下的组没有影响。

由于您正在在线升级群组，而在新群组中正在配置成员，因此需要新群组中的一个服务器作为来自旧群组的主服务器的副本。这确保了新群组可以跟上旧群组。因为这个方法依赖于异步复制通道，该通道用于从一个群组到另一个群组复制数据，因此它受同样的异步源-副本复制假设和要求的支持，见第19章,<i>复制</i>。对于单主模式的群组，异步复制连接到旧群组必须将数据发送到新群组中的主服务器，而对于多主模式的群组，异步复制通道可以连接到任何主服务器。

过程如下：

一旦新的组中缺少数据足够小，可以快速传输，您必须将写操作重定向到新组。等待所有来自旧组的数据都被传播到新组，然后断开异步复制连接。