MySQL 8.4 LTS → 9.x 升级支线

← 本站索引 ｜ 练习答案

MySQL 9.x 是创新版本序列。目标必须写成明确补丁版本；“升级到 9.x”不能作为可执行变更单。

升级前 SQL 基线

SELECT VERSION(), @@version_comment;
SELECT @@SESSION.sql_mode, @@character_set_server, @@collation_server;
SELECT PLUGIN_NAME, PLUGIN_STATUS
FROM information_schema.PLUGINS
ORDER BY PLUGIN_NAME;
SELECT user, host, plugin FROM mysql.user ORDER BY user, host;

MySQL Shell Upgrade Checker 示例在 mysqlsh JavaScript 模式运行：

util.checkForServerUpgrade(
  'admin@upgrade-clone:3306',
  {
    targetVersion: 'replace-with-exact-9.x-version',
    outputFormat: 'JSON'
  }
)

机制解释

升级检查发现已知不兼容对象、配置和功能，但不能证明应用 SQL、驱动、ORM、代理、备份工具及观测系统兼容。升级必须在从生产备份恢复出的克隆环境执行完整回归。

稳定流程是：锁定 8.4 基线 → 阅读目标版本发行说明 → Upgrade Checker → 备份恢复到克隆 → 升级克隆或候选副本 → 数据与应用回归 → 压测和故障演练 → 小流量切换 → 观察 → 扩大。

真实边界

• 不假设跨大版本原地降级可行；回滚通常依赖旧版本实例、兼容写入策略和升级前备份。
• 新旧版本并存时，schema 和写入必须保持回滚兼容。
• 每次只跨官方支持的升级路径；目标版本变化后重新执行检查。
• 复制混合版本、插件和托管服务限制必须按实际拓扑确认。

练习

1. 写升级清单，覆盖 server、schema、账户、驱动、ORM、备份、复制和监控。
2. 为一次候选副本升级定义通过与回滚指标。
3. 说明为什么 Upgrade Checker 通过仍不能直接升级生产。

验收清单

• 目标写成准确 9.x 补丁版本，并保存发行说明与检查器输出。
• 从生产备份创建的克隆完成 schema、数据和应用回归。
• 切换标准、停止条件、旧版本回滚路径和混合版本窗口明确。

完成后核对答案

深度加餐：升级支线要先证明可回退

8.4 LTS 到 9.x 的升级不是改版本号；先扫描弃用项、复制兼容和恢复路径。

先做一个可观察实验

SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE
FROM information_schema.TABLES
WHERE ENGINE NOT IN ('InnoDB', 'NDBCLUSTER');

SELECT VARIABLE_NAME, VARIABLE_VALUE
FROM performance_schema.global_variables
WHERE VARIABLE_NAME LIKE '%deprecated%';

预期：升级前得到引擎、变量和兼容性清单；真正的弃用项需结合目标版本官方说明与测试实例确认。

原理下潜与工程边界

升级计划包含备份、复制拓扑、扩展插件、SQL mode、字符集、认证和连接器；先在影子库执行 schema/data/查询回放，再安排灰度和回滚窗口。

降级通常不是原地反向启动；新数据字典或 redo/binlog 行为可能不可逆；第三方驱动与 ORM 的认证插件支持要单独验证。

反例排错路线

保留升级前后 EXPLAIN、错误日志、迁移耗时、复制延迟和恢复点；出现异常先停止扩散，再按 runbook 回滚流量或提升备用实例。

练习加码（仍不提供答案）

加码：写一份 8.4→9.x 彩排矩阵，覆盖 DDL、备份恢复、复制、连接器、权限和长事务六类风险。

验收时请补充：一份可复现的环境/数据前提、正常结果、失败结果以及可回滚或清理动作。

继续查阅：MySQL 8.4 参考手册（外部资料已收录于证据账本） · InnoDB 文档（外部资料已收录于证据账本）