MySQL主从升级须先从库后主库，确保版本兼容、备份完备、复制正常；升级后验证延迟、认证、执行计划及性能事件。
MySQL主从复制环境下升级版本，核心原则是先升级从库，再升级主库，避免因协议或binlog格式不兼容导致复制中断或数据不一致。
一、确认版本兼容性与升级路径
MySQL官方只保证相邻大版本间的平滑升级（如5.7 → 8.0），不支持跨多版本跳跃（如5.6 → 8.0）。必须查阅MySQL官方升级文档确认当前版本到目标版本是否被支持，并检查是否需要中间过渡版本。
- 5.7 → 8.0：支持，但需注意默认字符集、密码认证插件、系统表结构等变更
- 5.6 → 8.0：不支持直接升级，建议先升至5.7，再升至8.0
- 主从版本允许“从库版本 ≥ 主库版本”，但生产环境强烈建议主从版本完全一致
二、升级前关键准备动作
在任意节点操作前，务必完成以下检查和备份：
- 执行
mysql_upgrade前先停写或确保无DDL进行中；8.0.16+已废弃该命令，改由mysqld --upgrade自动处理 - 备份所有实例的
my.cnf配置文件，特别关注binlog_format、server_id、gtid_mode等复制相关参数 - 使用
mysqldump --all-databases --single-transaction --routines --events做逻辑全备，同时保留最近一次物理备份（如xtrabackup） - 在从库上运行
SHOW SLAVE STATUS\G，确认Seconds_Behind_Master = 0且无IO/SQL线程错误
三、主从分步升级操作流程
按“从库→主库”顺序升级，每步完成后验证复制状态和业务读取正常：
- 停止从库复制：
STOP SLAVE; - 关闭从库MySQL进程，替换二进制文件，启动新版本mysqld（首次启动会自动升级系统表）
- 启动后检查错误日志，确认无critical报错；执行
SELECT VERSION();和SHOW VARIABLES LIKE 'gtid_mode';核对版本与参数 - 重新开启复制：
START SLAVE;，观察SHOW SLAVE STATUS\G中Slave_IO_Running和Slave_SQL_Running均为Yes - 主库升级前，建议先将一个从库提升为新主（可选），再对原主库执行同样停服升级流程
四、升级后必验事项
版本升级不是结束，而是验证的开始：
- 检查复制延迟是否持续归零，对比主从
SELECT COUNT(*) FROM mysql.user;等关键表行数 - 确认应用连接未因认证插件变更（如
caching_sha2_password）失败，必要时为兼容旧客户端添加default_authentication_plugin=mysql_native_password - 测试典型SQL执行计划是否变化（尤其涉及JSON、窗口函数、隐藏索引等8.0新特性）
- 启用
performance_schema并检查是否存在大量statement/sql/*等待事件异常增长
不复杂但容易忽略。版本升级本质是配置、协议、数据字典三者的协同演进，稳住复制链路比跑通单点更重要。
