MySQL 8.0 → 8.4 LTS 升级（in-place）

在同一台服务器上把已安装的 MySQL 8.0 原地（in-place）升级到 8.4 LTS：单服务器、source + replica（先 replica，最后 source），或 InnoDB Cluster（Router → Shell → metadata → 逐个 secondary → 最后 primary）。包含每台服务器上的 util.checkForServerUpgrade 预检查、8.4 中已移除的变量和默认关闭的 mysql_native_password、用冷拷贝建立回退点、验证，以及回退到 8.0 的 runbook。由于不支持降级，回退的唯一途径是升级前的拷贝。如需迁移到新服务器（dump/load），请使用逻辑备份指南的“迁移到其他服务器”模式。

架构: 1 台服务器、source + replica，或 InnoDB Cluster（3+ 个成员 + MySQL Router 服务器）

开始之前

• 服务器运行的是 MySQL 8.0 的最新小版本（8.0.4x），且从官方 MySQL 仓库安装。支持从 8.0 直接升级到 8.4；不支持从 5.7 直接升级到 8.4（先升到 8.0）。
• … 下有与数据目录 + binlog 大小相当的可用空间（用于冷拷贝）。
• 有最近一次成功的备份（XtraBackup 8.0 或 mysqldump）和恢复测试。升级后必须改用 XtraBackup 8.4（8.0 版本无法备份 8.4 服务器）。
• 已在测试环境中验证应用和客户端驱动（JDBC、PHP mysqlnd、Python…）对 MySQL 8.4 和 caching_sha2_password 的支持。
• 维护窗口已批准…；由于 replica 逐个升级，读流量可能下降，升级 source 时会有写入中断…。
• source 上的 binlog 保留时间长于 replica 的升级时间（replica 停止期间仍需要的 binlog 不能被清除）。
• 集群健康：所有成员均为 ONLINE，single-primary 模式；表单中的第一个成员是当前 primary。存在 RECOVERING 成员或状态为 OK_PARTIAL / OK_NO_TOLERANCE 时不要开始升级。
• 集群管理账号 … 可以通过 … 端口连接所有成员，并且已知其密码（MySQL Shell 每次连接都会询问）。
• Router 服务器上的 MySQL Router 从官方 MySQL 仓库安装，并作为 systemd 服务（mysqlrouter）运行。如果应用流量经过多个 Router，则逐个升级 Router。
• 应用只通过 Router 连接（直接按成员名连接的应用在 primary 角色变化后无法写入）。

指南阶段

• 预检查 — 当前状态 · 添加 8.4 仓库并安装 MySQL Shell 8.4 · 运行 Upgrade Checker · 在配置中查找已移除的变量 · 迁移 mysql_native_password 账号
• InnoDB Cluster 预检查 — 记录集群状态和 Router · 检查是否需要升级 metadata（dryRun）
• Metadata 升级 — 运行 dba.upgradeMetadata()
• 准备 primary 切换 — 验证 secondary 已升级到 8.4 并处于 ONLINE
• InnoDB Cluster 最终检查 — 检查扩展的集群状态 · 把 primary 角色交还给第一个成员
• 升级之后 — 检查复制（…） · 把 XtraBackup 升级到 8.4 并做一次新的全量备份 · 迁移 mysql_native_password 账号（永久方案） · 何时删除回退拷贝
• 回退（回到 8.0） — 回退：停止 8.4，把数据目录移到一边 · 回退：停止 8.4，把数据目录移到一边 · 回退：恢复 8.0 软件 · 回退：恢复 8.0 软件 · 回退：恢复冷拷贝 · 回退：恢复冷拷贝 …