主从架构的 MySQL 升级，核心是“不中断服务、不丢数据、可回退”。重点不是版本号跳变，而是升级过程中的角色切换、数据一致性保障和故障兜底机制。
一、明确升级目标与约束条件
先厘清几个关键问题：是只升主库、还是主从一起升？是否允许短时只读？从库是否承担读流量？binlog 格式是否兼容（如 ROW 必须）？现有 GTID 是否开启？这些直接决定能否用滚动升级或必须停机切换。
若主从版本跨大版本（如 5.7 → 8.0），建议先升级从库，再主从切换，最后升级原主库 若仅小版本升级（如 5.7.32 → 5.7.40），且已开启 GTID + ROW 格式，可考虑在线滚动升级 禁止跳过中间版本（如 5.6 → 8.0），必须经 5.7 中转并完成兼容性检查二、升级前必须做的三件事
很多故障源于准备不足。这三步不做，升级大概率失败或回滚困难。
全量校验与备份：用 mysqldump --single-transaction --routines --triggers 或 mydumper 备份主库；同时用 pt-table-checksum 校验主从数据一致性 配置兼容性检查：运行 mysql_upgrade --dry-run（新版本二进制下执行），检查系统表、密码插件、SQL mode 等是否冲突 关闭自动 failover 工具：如 MHA、Orchestrator、ProxySQL 健康检查等，避免升级中误触发主从切换三、推荐的滚动升级流程（GTID + 从库先行）
这是最稳妥、适用性最广的方式，适用于生产环境有读写分离且不能长时间中断的场景。
停止一个从库的复制：STOP SLAVE; 停掉该从库 MySQL 进程，替换为新版本二进制，修改 my.cnf（注意 innodb_log_file_size、default_authentication_plugin 等新增/变更参数） 启动新版本从库，确认 SHOW SLAVE STATUS\G 中 Seconds_Behind_Master = 0 且无报错 重复以上步骤，逐台升级其余从库（保留至少一台旧版从库作为回滚锚点） 主从切换：将业务流量切到最新版从库（需提前配置好读写分离路由），再执行 STOP SLAVE; RESET SLAVE ALL; 将其提升为主库 原主库降级为从库，按同样流程升级后重新接入复制链路四、升级后必须验证的五项
上线不等于成功，验证不到位等于埋雷。
确认 SELECT @@version; 和 SELECT @@gtid_mode; 符合预期 检查慢查询日志、错误日志是否有新版本特有的 warning（如密码过期策略、默认字符集变更） 跑一遍核心业务 SQL，特别是含 JSON、窗口函数、CTE 的语句，确认语法和性能无异常 用 pt-heartbeat 检查主从延迟是否稳定在毫秒级 模拟一次主库宕机，验证新主库能否被正确识别并接管流量（尤其使用 VIP 或 DNS 切换的场景）不复杂但容易忽略的是升级节奏控制和验证闭环。每次只动一个节点，每步都留回滚点，每步之后必验证——这才是主从架构升级真正落地的关键。
