本节说明升级组成员所需的步骤。此过程是 第 20.8.3.3 节,“组复制在线升级方法” 中描述的方法的一部分。升级组成员的过程在所有方法中都是通用的,首先进行说明。加入已升级成员的方式可能取决于您遵循的方法以及其他因素,例如组是否在单主模式或多主模式下运行。您使用就地或配置方法升级服务器实例的方式不会影响此处描述的方法。
升级成员的过程包括从组中删除成员,按照您选择的升级成员方法进行升级,然后将已升级成员重新加入组。在单主组中,升级成员的推荐顺序是先升级所有辅助节点,最后升级主节点。如果在辅助节点之前升级主节点,将选择使用旧版 MySQL 版本的新主节点,但此步骤没有必要。
要升级组成员
将客户端连接到组成员并发出
STOP GROUP_REPLICATION
。在继续操作之前,通过监控replication_group_members
表确保成员状态为OFFLINE
。禁用组复制自动启动,以便您在升级后可以安全地连接到成员并进行配置,而不会重新加入组,方法是设置
group_replication_start_on_boot=0
。重要提示如果已升级成员具有
group_replication_start_on_boot=1
,则它可能会在您执行 MySQL 升级过程之前重新加入组,并可能导致问题。例如,如果升级失败并且服务器再次重新启动,则可能损坏的服务器可能会尝试加入组。停止成员,例如使用 mysqladmin shutdown 或
SHUTDOWN
语句。组中的任何其他成员将继续运行。使用就地或配置方法升级成员。有关详细信息,请参阅 第 3 章,升级 MySQL。在重新启动已升级成员时,因为
group_replication_start_on_boot
设置为 0,组复制不会在实例上启动,因此它不会重新加入组。在成员上执行完 MySQL 升级过程后,必须将
group_replication_start_on_boot
设置为 1,以确保组复制在重启后正确启动。重新启动成员。连接到已升级成员并发出
START GROUP_REPLICATION
。这将使成员重新加入组。组复制元数据存在于已升级服务器上,因此通常不需要重新配置组复制。服务器必须赶上组在服务器脱机期间处理的任何事务。一旦赶上组,它将成为组的在线成员。注意升级服务器所需的时间越长,该成员脱机的时间就越长,因此服务器在添加回组时赶上的时间就越长。
当已升级成员加入任何运行早期 MySQL 服务器版本的成员的组时,已升级成员将使用 super_read_only=on
加入。这将确保在所有成员都运行较新版本之前,不会对已升级成员进行写入。在多主模式组中,当升级成功完成并且组已准备好处理事务时,打算作为可写主节点的成员必须设置为读写模式。当组中的所有成员都升级到同一版本时,它们将自动全部更改回读写模式。