MySQL 升级后 mysqldump
备份脚本还能直接用吗
大多数情况下能，但必须验证
--set-gtid-purged和
--skip-lock-tables的行为变化。MySQL 5.7 升级到 8.0 后，GTID 默认开启且更严格，
mysqldump --set-gtid-purged=auto在非 GTID 实例中可能报错
ERROR 1238 (HY000): Variable 'gtid_mode' is a read only variable；若升级前没开 GTID，备份时应显式加
--set-gtid-purged=OFF，否则 dump 文件头部会插入无效的
SET @@GLOBAL.GTID_PURGED语句，导致恢复失败。 检查当前实例是否启用 GTID：
SELECT @@gtid_mode;，结果为
ON才可安全使用
--set-gtid-purged=AUTO跨大版本迁移（如 5.6→8.0）时，
mysqldump命令本身建议用目标版本的客户端，避免字符集或权限语法兼容问题 若备份含
DEFINER子句的视图或存储过程，升级后用户权限模型变更（如
mysql.session系统账户），恢复时可能报
ERROR 1449 (HY000): The user specified as a definer ('xxx'@'%') does not exist，需提前用 --skip-definer或手动替换
Percona XtraBackup 升级后能否继续用于物理备份
不能直接沿用旧版本。XtraBackup 8.0 只支持 MySQL 8.0 及 Percona Server 8.0，与 MySQL 5.7 不兼容；同样，XtraBackup 2.4 最高只支持 MySQL 5.7。升级 MySQL 前必须同步升级 XtraBackup，并注意
xtrabackup二进制文件路径、配置项名变化（如
--defaults-file仍可用，但
--slave-info在 8.0 中已改名为
--source-info）。 MySQL 8.0 使用了新的数据字典表（存于
mysql.ibd），XtraBackup 2.4 无法识别，执行
backup会卡在
Starting to parse ibdata files...或报
Unknown redo log format
xtrabackup --prepare阶段若提示
InnoDB: Unsupported redo log format，说明 XtraBackup 版本太低，必须换用 8.0+ 版本 备份时若启用了 MySQL 8.0 的原子 DDL（默认开启），XtraBackup 8.0 会自动处理，但恢复后需确认
mysql.innodb_ddl_log表为空，否则说明有未完成的 DDL 操作
升级后 binlog 备份和基于位点的恢复还可靠吗
不可靠，位点（
File/
Position）在 MySQL 8.0 中已不推荐依赖。8.0 默认启用 GTID，且 binlog 事件格式从
STATEMENT改为
ROW（尤其涉及 JSON 或生成列时），
SHOW MASTER STATUS返回的
Position值不再具备跨实例一致性——同一事务在不同从库上可能产生不同位点值。强行用旧脚本解析
mysql-bin.000001+ 位置号做 PITR，极易跳过或重复执行事务。 升级后应立即切换为 GTID 模式恢复：
CHANGE MASTER TO MASTER_AUTO_POSITION = 1;，备份脚本中记录
SELECT BINLOG_GTID_POS('mysql-bin.000001', 12345); 替代传统位点
binlog 保留策略要重设：expire_logs_days已被弃用，改用
binlog_expire_logs_seconds（单位秒），例如设为 604800 表示保留 7 天 若仍需解析 binlog（如审计或补数），
mysqlbinlog --base64-output=DECODE-ROWS -v输出中，
###开头的行才是真实变更，旧脚本若正则匹配
UPDATE.*WHERE可能漏掉 ROW 格式内容
备份文件恢复到新版本 MySQL 时最常踩的坑
不是编码或权限问题，而是系统表结构不兼容。MySQL 8.0 的
mysql库是 InnoDB 引擎且含隐藏字段（如
account_locked），而 5.7 的
mysqldump备份中
mysql.user表结构不含这些字段，直接
source会报
ERROR 1682 (HY000): Native table 'mysql'.'user' has the wrong structure。 不要用
mysqldump全库备份恢复系统库：
mysql、
performance_schema、
information_schema必须由 MySQL 实例初始化生成，备份脚本中应排除它们：
mysqldump --all-databases --ignore-table=mysql.user --ignore-table=mysql.db ...用户密码哈希方式变了：8.0 默认用
caching_sha2_password，若备份中含
CREATE USER ... IDENTIFIED WITH mysql_native_password，恢复后连接会报
Authentication plugin 'caching_sha2_password' cannot be loaded，需统一指定插件或升级客户端驱动 字符集相关参数如
collation_server在 8.0 中默认为
utf8mb4_0900_ai_ci，若应用仍用
utf8mb4_general_ci，备份恢复后查询可能因排序规则差异返回不同结果，建议在备份前执行
SET NAMES utf8mb4 COLLATE utf8mb4_0900_ai_ci;再 dump 备份策略调整的本质，是承认 MySQL 8.0 不再向后兼容“看起来一样”的行为——哪怕命令没报错，结果也可能偏离预期。最易被忽略的是系统库处理方式和 GTID 启用状态的隐式依赖，这两点不手动验证，自动化脚本大概率会在某次升级后的首次恢复中暴露问题。
