升级前的备份与回退预案是什么
MySQL 大版本升级（例如 5.7 到 8.0）一旦启动数据字典升级就不可逆：旧版本无法再启动这份数据。因此升级前的准备要成套：升级检查器先扫出不兼容项，逻辑全备保底可跨版本读取，物理全备负责快速回退，再加上可执行的回退预案与回退时间估算。只做其中一项，等于把风险押在「升级一定成功」上。
基本信息
| 升级方式 | 原地升级（in-place）或逻辑导出再导入（dump and load） |
|---|---|
| 兼容检查 | mysqlcheck --all-databases --check-upgrade、mysqlsh util.checkForServerUpgrade |
| 逻辑全备 | mysqldump --single-transaction --routines --events --all-databases |
| 物理全备 | XtraBackup 全备，回退最快 |
| 回退前提 | 物理备份可恢复、旧版本二进制与配置已保留 |
| 耗时评估 | 备份 + 恢复演练的实际时长，写进回退预案 |
典型使用场景
- 业务系统从 5.7 升级到 8.0 前的准备工作
- 小版本升级（如 8.0.x 到 8.0.y）前的例行保障
- 升级窗口发版计划评审：给出可回退的时间点与判断条件
- 预发环境预演升级流程，验证应用与新版本的兼容性
- 云上实例变更规格或版本时，提前准备本地独立备份兜底
升级前检查与备份
升级前检查与备份
# 1) 兼容性检查：保留字冲突、弃用语法与数据类型问题
mysqlcheck -uroot -p --all-databases --check-upgrade
# 2) 逻辑全备（保底，可跨版本读取）
mysqldump -uroot -p --single-transaction --routines --events \
--all-databases | gzip > /data/backup/pre_upgrade_$(date +%F).sql.gz
# 3) 物理全备（回退最快）
xtrabackup --backup --user=backup --password='***' \
--target-dir=/data/backup/pre_upgrade_pxb
# 4) 备份校验：确认文件可读、行数正常，别等到回退时才发现坏了
ls -lh /data/backup/ | tail -3升级检查器与验收
升级检查器与验收
# 使用 MySQL Shell 做更细的升级前检查（8.0 环境）
mysqlsh -- util check-for-server-upgrade root@localhost:3306 \
--output-format=text --config-path=/tmp/upgrade_check
# 升级后跑关键业务查询做回归，并对比前后执行计划
mysql -uroot -p -e 'SELECT VERSION();'
mysql -uroot -p appdb -e 'EXPLAIN SELECT * FROM orders WHERE user_id = 42;'备份方式对照
| 方式 | 恢复速度 | 适用范围 |
|---|---|---|
| 物理全备 | 快（文件级拷贝） | 原地回退主路径，版本必须与目标一致 |
| 逻辑全备 | 慢（重建表与索引） | 跨版本保底，可挑表恢复 |
| mysqldump 单库 | 慢 | 小库或特定库的保底备份 |
| 从库提升 | 最快 | 有可用从库时优先作为回退手段 |
升级不可逆：数据字典升级完成后旧版本二进制无法启动这份数据。执行前必须确认三件事——备份已验证可恢复、旧版本二进制与配置文件仍在、回退操作有人会做且知道要多久。
升级兼容项要逐条对照官方升级说明：保留字冲突（新关键字做表名或列名）、字符集默认值变化、弃用参数被移除、认证插件默认值变化，这些在生产上表现为启动失败或应用连接报错。