先升级从库再依次升级主库，确保版本兼容性。需备份数据、检查GTID兼容性，停止复制通道后升级MySQL软件，运行mysql_upgrade更新系统表，逐个启动通道并验证复制状态。注意测试环境模拟、binlog格式、过滤规则变化及复制延迟监控，推荐双从架构试升级，避免复制中断。
MySQL 多源复制环境的升级需要谨慎操作，确保主从数据一致性以及复制拓扑的稳定性。多源复制（Multi-Source Replication）是指一个从库（Replica）同时从多个主库（Source）复制数据，常见于数据汇总、分析等场景。升级这类环境时，不能简单套用单主复制的流程。
理解多源复制架构
在多源复制中，每个主库对应一个独立的复制通道（Channel），每个通道有自己的一组中继日志、IO线程和SQL线程。这意味着：
- 每个通道可以独立运行、停止或出错
- 升级时必须考虑所有通道的状态
- 版本兼容性需覆盖所有主库与从库之间的通信
因此，升级前要确认当前拓扑结构、各主库 MySQL 版本、从库版本以及 GTID 使用情况。
制定升级策略
推荐采用“先主后从”或“逐级滚动”的方式，避免服务中断：
- 优先升级从库：由于多源复制的从库接收多个主库的数据，建议先将从库升级到目标版本，前提是新版本兼容旧主库的协议
- 再依次升级各个主库
- 若主库之间也存在复制关系，需按拓扑顺序升级
注意：MySQL 官方建议主库版本不低于从库版本，因此从库升级前必须确认其支持与当前主库版本的复制兼容性。
执行升级步骤
以下是安全升级多源复制从库的操作流程：
- 备份所有节点数据：包括所有主库和从库，使用 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 报错
- 对于关键业务，建议采用双从架构，在备用从库上先试升级
基本上就这些。只要按通道逐一处理，保持版本兼容，多源复制升级并不复杂，但容易忽略细节导致复制断裂。提前规划、充分测试是成功的关键。