MySQL数据库如何进行版本升级

MySQL 版本升级实操指南

一 升级总览与方式选择

• 明确升级类型：是小版本（同一 LTS 系列内）还是大版本（跨 LTS 系列）。小版本升级相对直接；大版本升级需充分评估与测试。
• 三种常用方式：
  • 就地升级 In-place：替换 MySQL 服务器软件包，保留现有数据目录与配置，快速但风险相对高。
  • 逻辑升级 Logical：用 mysqldump 导出为 SQL 并在新实例导入，兼容性最好，适合跨大版本或做结构性变更。
  • 复制拓扑升级：在复制链路中逐节点升级，保证业务连续性，适合高可用架构。
• 支持矩阵与平台：确认目标版本对当前 操作系统/平台 的支持；若平台不再支持，需先升级操作系统或改用逻辑升级。
• 规划窗口与回滚：选择低峰时段，准备回滚方案（如保留旧实例快照或快速切回复制从库）。

二 升级前检查与准备

• 完整备份与可恢复性验证：备份所有数据库与配置，包含 my.cnf/my.ini、SSL 证书、复制信息与必要的 二进制日志；在测试环境做一次全量恢复演练。
• 使用 MySQL Shell 的升级检查器：在旧库上执行 util.checkForServerUpgrade()，目标版本选择计划升级到的版本，逐项修复不兼容问题（如数据类型、存储引擎、系统变量、权限表结构差异等）。
• 兼容性评估：阅读目标版本的“行为变更/弃用/移除”说明；关注 SQL 模式、默认字符集、认证插件（如 caching_sha2_password）、索引/分区/数据类型变更等。
• 平台与依赖：确认 glibc、库依赖、磁盘空间、内存与 I/O 能力满足新版本要求。
• 应用侧准备：梳理驱动/连接器版本，准备连接串与认证方式的兼容性调整；在测试环境进行功能与性能回归。
• 复制拓扑：如为复制环境，设计逐节点升级顺序与一致性校验方案。

三 标准升级流程

• 就地升级（In-place）
  1. 进入维护窗口，执行“慢关闭”：SET GLOBAL innodb_fast_shutdown=0;，随后 mysqladmin shutdown。
  2. 使用系统包管理器升级软件包（如 YUM/DNF/APT），或替换二进制；保留原有 datadir 与 my.cnf。
  3. 启动新版本，观察 error log 是否有升级提示。
  4. 在 MySQL 8.0+ 多数情况下系统表会在启动时自动升级；早期版本或需要时执行 mysql_upgrade -u root -p 并重启。
  5. 登录验证：SELECT VERSION(); 并检查系统库、用户权限、存储引擎可用性。
• 逻辑升级（Logical）
  1. 在旧库导出：mysqldump -u root -p --all-databases --routines --triggers --events --single-transaction --hex-blob > backup.sql（如启用 GTID，建议导出时保持 gtid_mode 一致，避免导入后执行 SET @@GLOBAL.GTID_PURGED 不当）。
  2. 安装并初始化新版本实例（注意新版本对 root 临时密码与目录权限的要求）。
  3. 导入数据：mysql -u root -p < backup.sql。
  4. 启动新实例，执行必要升级步骤（如 8.0+ 通常无需手动 mysql_upgrade）。
  5. 验证数据一致性与应用连通性。
• 复制拓扑升级
  • 建议按“从库→主库”顺序逐节点升级；每步完成后校验复制一致性、延迟与错误日志。
  • 如采用 InnoDB Cluster/Group Replication，遵循相应官方升级流程与版本约束。

四 升级后验证与回滚

• 版本与系统状态：确认 SELECT VERSION(); 正确；检查 error log 无异常；验证 InnoDB、复制、插件、定时任务等状态。
• 数据与应用：随机抽样查询与关键业务回归；对比升级前后 QPS/延迟/错误率；如性能退化，复核参数（如排序缓冲、连接数、InnoDB 缓冲池）、索引与执行计划。
• 认证与连接：确认客户端驱动兼容新 认证插件；必要时调整用户 ALTER USER ... IDENTIFIED WITH ...。
• 回滚策略：若发现问题，优先切回旧实例或复制从库；逻辑升级可直接切回旧库并重新导入；就地升级依赖快照/备份快速回滚。

五 常见注意事项与排错要点

• 平台支持：目标版本若不再支持当前 操作系统，就地升级不被支持，应升级 OS 或改用逻辑升级。
• 大版本差异：如 5.7 → 8.0 涉及系统库与权限表结构重构（如 mysql.user 字段与插件体系变化），务必先跑 Upgrade Checker 并修正不兼容项。
• 复制与 GTID：跨版本导入导出时保持 gtid_mode 策略一致，避免复制异常；必要时在导入后正确设置 GTID_PURGED。
• 认证与驱动：升级后应用若报认证失败，检查用户使用的 caching_sha2_password 是否被客户端支持，必要时调整用户认证方式或升级驱动。
• 性能回归：新版本可能改变优化器与加密/认证开销；通过基准测试定位慢查询并调整索引/参数。
• 日志与诊断：升级失败优先查看 error log 与 util.checkForServerUpgrade() 报告，逐项修复后再重试。