先升级从库再依次升级主库，确保版本兼容性。需备份数据、检查GTID兼容性，停止复制通道后升级MySQL软件，运行mysql_upgrade更新系统表，逐个启动通道并验证复制状态。注意测试环境模拟、binlog格式、过滤规则变化及复制延迟监控，推荐双从架构试升级，避免复制中断。
理解多源复制架构
在多源复制中，每个主库对应一个独立的复制通道（Channel），每个通道有自己的一组中继日志、IO线程和SQL线程。这意味着：
- 每个通道可以独立运行、停止或出错
- 升级时必须考虑所有通道的状态
- 版本兼容性需覆盖所有主库与从库之间的通信
制定升级策略
推荐采用“先主后从”或“逐级滚动”的方式，避免服务中断：
- 优先升级从库：由于多源复制的从库接收多个主库的数据，建议先将从库升级到目标版本，前提是新版本兼容旧主库的协议
- 再依次升级各个主库
- 若主库之间也存在复制关系，需按拓扑顺序升级
执行升级步骤
以下是安全升级多源复制从库的操作流程：
- 备份所有节点数据：包括所有主库和从库，使用 mysqldump 或物理备份工具（如 Percona XtraBackup）
- 检查 GTID 兼容性：如果启用了 GTID，确保新版本支持原有 GTID 格式。MySQL 5.7+ 到 8.0+ 需特别注意 gtid_executed 表结构变化
-
停止从库复制通道：
STOP SLAVE;
此命令会停止所有通道。也可指定通道：
STOP SLAVE FOR CHANNEL 'source1';
-
关闭 MySQL 服务：
mysqladmin shutdown
- 执行软件升级：替换二进制文件或使用包管理器升级（yum/dpkg），注意保留原配置文件
-
启动 MySQL 并运行 mysql_upgrade：
mysqld --upgrade=FORCE
或在启动后执行：mysql_upgrade
此步更新系统表，修复元数据不一致问题 -
验证复制状态：逐个启动通道并检查是否正常：
START SLAVE FOR CHANNEL 'source1';
使用 SHOW REPLICA STATUS FOR CHANNEL 'source1'\G 查看 Seconds_Behind_Master 和错误信息
注意事项与最佳实践
- 升级前在测试环境模拟整个流程，尤其是跨大版本（如 5.7 → 8.0）
- 关注 binlog format 和 row image 设置，避免因格式不兼容导致复制中断
- 若使用 replication filters（如 replicate-do-db），确认其在新版本中的行为是否改变
- 监控复制延迟和错误日志，及时处理 SQL_THREAD 或 IO_THREAD 报错
- 对于关键业务，建议采用双从架构，在备用从库上先试升级
