前往新版Gitcode，体验更适合开发者的 AI 搜索 >>
#### 18.8.3.2 升级组复制成员 [](<>) 本节介绍升级组成员所需的步骤。此过程是描述的方法的一部分[第 18.8.3.3 节，“组复制在线升级方法”](group-replication-online-upgrade-methods.html).升级组成员的过程对所有方法都是通用的，因此首先进行说明。您加入升级成员的方式可能取决于您遵循的方法以及其他因素，例如该组是在单主模式还是多主模式下运行。您如何使用就地或预配方法升级服务器实例不会影响此处描述的方法。 升级成员的过程包括将其从组中删除，按照您选择的升级成员的方法，然后将升级后的成员重新加入组。单主组中升级成员的推荐顺序是先升级所有从节点，然后再升级主节点。如果主节点在辅助节点之前升级，则选择使用旧 MySQL 版本的新主节点，但不需要此步骤。 要升级组的成员： - 将客户端连接到组成员并发出[`停止 GROUP_REPLICATION`](stop-group-replication.html).在继续之前，请确保会员的状态是`离线`通过监测[`复制组成员`](performance-schema-replication-group-members-table.html)桌子。 - 禁用组复制自动启动，以便您可以在升级后安全地连接到成员并配置它，而无需通过设置重新加入组[`group_replication_start_on_boot=0`](group-replication-options.html#sysvar_group_replication_start_on_boot). 重要的 如果升级会员有[`group_replication_start_on_boot=1`](group-replication-options.html#sysvar_group_replication_start_on_boot)那么它可能会在您执行 MySQL 升级过程之前重新加入该组，并可能导致问题。例如，如果升级失败并且服务器再次重新启动，则可能损坏的服务器可能会尝试加入该组。 - 停止成员，例如使用[**mysqladmin 关闭**](mysqladmin.html)或者[`关掉`](shutdown.html)陈述。组中的任何其他成员继续运行。 - 使用就地或供应方法升级成员。看[第 2.11 节，“升级 MySQL”](upgrading.html)详情。重新启动升级后的成员时，因为[`group_replication_start_on_boot`](group-replication-options.html#sysvar_group_replication_start_on_boot)设置为 0，组复制不会在实例上启动，因此它不会重新加入组。 - 在成员上执行 MySQL 升级过程后，[`group_replication_start_on_boot`](group-replication-options.html#sysvar_group_replication_start_on_boot)必须设置为 1 以确保组复制在重新启动后正确启动。重新启动成员。 - 连接到升级的成员并发布[`开始 GROUP_REPLICATION`](start-group-replication.html).这会将成员重新加入组。Group Replication 元数据在升级后的服务器上就位，因此通常不需要重新配置 Group Replication。当服务器离线时，服务器必须赶上组处理的任何事务。一旦它赶上该组，它就成为该组的在线成员。 笔记 升级服务器所需的时间越长，该成员脱机的时间就越长，因此服务器在添加回组时赶上所需的时间也就越多。 当升级的成员加入一个有任何成员运行早期 MySQL 服务器版本的组时，升级的成员加入[`super_read_only=on`](server-system-variables.html#sysvar_super_read_only).这可确保在所有成员都运行较新版本之前，不会对升级的成员进行写入。在多主模式组中，当升级成功完成并且组准备好处理事务时，必须将用作可写主模式的成员设置为读写模式。从 MySQL 8.0.17 开始，当一个组的所有成员都升级到同一个版本时，它们都会自动变回读写模式。对于早期版本，您必须手动将每个成员设置为读写模式。连接到每个成员并发布： ``` SET GLOBAL super_read_only=OFF; ```
