升级前必须做完整逻辑备份，而非仅依赖物理快照；正确做法是用mysqldump或mydumper执行在线备份并指定--single-transaction、--master-data=2等参数，备份后需校验表结构与导出头。
升级前必须做完整逻辑备份，而非仅依赖物理快照
容器环境里直接 docker commit 或宿主机打卷快照，无法保证 MySQL 数据一致性——InnoDB 的 redo log、buffer pool、binlog 位置可能未刷盘。一旦升级失败回退，极大概率遇到主从断裂、GTID 不连续或表损坏。
正确做法是用 mysqldump 或 mydumper 执行在线逻辑备份，并显式指定关键参数：
-
--single-transaction：确保 InnoDB 表一致性（但不适用于 MyISAM） -
--master-data=2：记录当前 binlog 文件与 position，方便后续重搭复制 -
--routines --triggers --events：避免存储过程、事件丢失 - 备份后务必校验：
mysqlcheck -c检查表结构，head -n 20 backup.sql | grep "CREATE TABLE"确认导出头正常
使用官方镜像 + 显式版本标签，禁止用 :latest
MySQL 官方 Docker 镜像（mysql:8.0.33）按语义化版本发布，但 :latest 始终指向最新 minor 版，可能跳过中间修复补丁，甚至引入不兼容变更（如 8.0.32 → 8.0.33 默认启用 caching_sha2_password 认证插件）。
升级时应：
- 先在测试容器中拉取目标镜像：
docker pull mysql:8.0.33 - 启动时挂载原有
/var/lib/mysql卷，但加--skip-networking和--innodb-force-recovery=1（仅诊断用） - 观察日志是否出现
InnoDB: Upgrade is required或Unknown system variable类错误 - 确认无误后再正式替换生产容器的
image字段
升级后必须运行 mysql_upgrade（8.0.16+ 已弃用，改用 ALTER）
MySQL 8.0.16 起移除了 mysql_upgrade 工具，系统表升级由 mysqld 自动完成，但你仍需手动触发元数据兼容性操作：
- 若从 5.7 升级到 8.0，首次启动会自动执行
ALTER TABLE mysql.user CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci等操作；需关注错误日志中是否卡在Waiting for upgrade to complete - 检查
performance_schema表是否全部存在：SELECT COUNT(*) FROM information_schema.tables WHERE table_schema = 'performance_schema（8.0 应返回 87+）
';
- 验证 SQL mode 是否符合预期：
SELECT @@sql_mode;，8.0 默认含STRICT_TRANS_TABLES,ONLY_FULL_GROUP_BY，应用可能报错
滚动升级不适用于单节点容器，主从切换才是安全路径
试图对单个 MySQL 容器执行「停旧启新」看似简单，实则风险极高：连接中断期间未落盘事务丢失、应用重连时遭遇 Lost connection to MySQL server、连接池复用旧连接导致认证失败（尤其密码哈希算法变更）。
真正可行的做法是构建最小主从拓扑：
- 用新版本镜像起一个从库容器，配置
CHANGE REPLICATION SOURCE TO指向原主库 - 等
SHOW REPLICA STATUS\G中Seconds_Behind_Source为 0 后，执行STOP REPLICA - 将应用流量切至新实例（通过 DNS 切换或服务发现更新），再关闭旧主库
- 旧主库可降级为新集群的从库，或彻底下线
这个过程暴露的问题最真实：比如 8.0 不再支持 query_cache_type 参数，配置文件里留着就会导致从库启动失败——这种细节，只有实际跑起来才看得见。
