#将 MySQL 8.0 升级到 8.4

从 v4.4.0 开始，您可以将现有的 MySQL 8.0 MGR 集群原地升级到 MySQL 8.4，无需重建集群或迁移数据。operator 会逐个成员执行滚动升级：保留数据和 Group Replication 成员关系，自动升级 InnoDB Cluster 元数据架构，并且集群会在滚动重启期间继续通过 MySQL Router 提供流量服务。

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

#前提条件

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

1. operator 已升级到 v4.4.0 或更高版本。 8.0 → 8.4 升级功能由 v4.4.0 operator 提供。请先升级 Alauda Data Services Relational Database E1-MGR operator；operator 升级后，现有 8.0 实例会继续正常运行。
2. 存在最新备份。 由于主版本升级无法回滚，请在继续操作前对实例执行完整备份（或确认已有最新的自动备份）。如果发生任何问题，您可以使用此备份将数据恢复到新实例。
3. 集群运行状况良好。 所有成员必须处于 ONLINE 状态，并且实例必须处于 Ready 状态。请勿在状态不佳的集群上开始升级。
4. 每个成员至少具有 2Gi 内存。 8.4 server 启动时需要的内存多于 8.0。确保每个成员的内存限制为 ≥ 2Gi；如有需要，请先增大实例规格。
5. 建议使用 Single-Primary 拓扑。 原地升级已针对 Single-Primary 集群进行验证。

#升级操作步骤

#升级期间发生的情况

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

1. 执行预检查。 系统会检查每个成员是否已准备好升级（等同于 MySQL checkForServerUpgrade 工具）。如果某个成员未处于安全的复制一致性状态，operator 会先对其进行协调，因此即使集群从混合状态开始，升级也能安全进行。所有预检查通过后，升级才会继续。

2. 逐个滚动升级成员。 系统会先升级次要成员；在升级当前主成员之前，会先移交主角色（主动卸任），因此始终会有一个活动主成员。在整个过程中，MySQL Router 会持续将读写流量路由到可用的主成员。

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

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

#验证升级

升级完成后，请确认：

• 实例状态为 Ready，报告的版本为 8.4.x。
• 所有 Group Replication 成员均为 ONLINE（三成员集群应为 3/3）。
• 通过 MySQL Router 的读写连接均成功。
• 应用数据完整无误。

#故障排除

• 集群未返回 Ready。 请检查每个成员是否满足内存前提条件（≥ 2Gi），以及集群在升级前是否运行状况良好。检查实例事件和成员状态。
• 需要回滚。 大版本升级无法原位回滚。请将前提条件中创建的备份恢复到一个新实例，然后将应用重定向到该实例。