17370845950

升级前必须做完整逻辑备份，而非仅依赖物理快照；正确做法是用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 参数，配置文件里留着就会导致从库启动失败——这种细节，只有实际跑起来才看得见。