#升级 MySQL 8.0 到 8.4

从 v4.4.0 开始，您可以将现有的 MySQL 8.0 MGR cluster 原地升级到 MySQL 8.4，而无需重建 cluster 或迁移数据。operator 会执行滚动式、逐个 member 的升级：数据和 Group Replication membership 会保留，InnoDB Cluster 元数据 schema 会自动升级，并且 cluster 在滚动重启期间会通过 MySQL Router 持续提供服务。

这是一次 大版本 升级。与补丁升级不同，它 不可回滚——请规划维护窗口，并确保在开始前已有最新备份。

#前提条件

开始升级之前，请确认以下所有条件：

1. operator 已升级到 v4.4.0 或更高版本。 8.0 → 8.4 的升级能力由 v4.4.0 operator 提供。请先升级 Alauda Database Service for MySQL-MGR operator；在 operator 升级后，现有的 8.0 实例会继续保持不变地运行。
2. 已有最近的备份。 由于大版本升级无法回滚，请在继续之前对实例执行完整备份（或确认已有最近的自动备份）。如果发生任何问题，您可以基于该备份恢复到一个新的实例。
3. cluster 处于健康状态。 所有 member 必须为 ONLINE，并且实例必须处于 Ready 状态。不要在降级的 cluster 上开始升级。
4. 每个 member 至少具有 2Gi 内存。 8.4 server 在启动时所需内存高于 8.0。请确保每个 member 的内存限制 ≥ 2Gi；如有需要，请先提高实例规格。
5. 建议使用单主模式。 原地升级已在单主 cluster 上完成验证。

#升级操作步骤

#升级期间会发生什么

在您触发升级后，operator 将执行以下操作：

1. 运行预检查。 会检查每个 member 的升级准备情况（等同于 MySQL checkForServerUpgrade utility）。如果某个 member 不处于安全的 replication-consistency 状态，operator 会先进行修复，因此即使从混合状态开始，升级也是安全的。只有在所有预检查都通过后，升级才会继续。

2. 逐个滚动升级 member。 会先升级 secondary member；在升级当前 primary 之前，会先将 primary 角色转移（abdicated）出去，因此始终会有一个 active primary。MySQL Router 会在整个过程中持续将读写流量路由到可用的 primary。

3. 升级 InnoDB Cluster 元数据。 cluster metadata schema 会自动升级到 8.4 所需的版本。

4. 完成。 当每个 member 都运行 8.4 后，实例会报告新版本，并在 Group Replication 完全重新收敛后返回 Ready 状态。

#验证升级

升级完成后，请确认：

• 实例状态为 Ready，且报告的版本为 8.4.x。
• 所有 Group Replication member 均为 ONLINE（对于三 member cluster，显示为 3/3）。
• 通过 MySQL Router 的读写连接可正常访问。
• 您的应用数据保持完整。

#故障排查

• cluster 未返回到 Ready。 检查每个 member 是否满足内存前提条件（≥ 2Gi），以及升级前 cluster 是否处于健康状态。检查实例事件和 member 状态。
• 您需要回滚。 大版本升级无法原地逆转。请将前提条件中创建的备份恢复到一个 新的 实例，然后将应用切换到该实例。