先升级从库再逐个升级主库，确保数据一致性。需确认拓扑结构、版本兼容性及GTID设置，备份配置文件并在测试环境验证。停止从库复制线程后升级软件，重启并监控复制状态。每次仅升级一个主库，切换流量、待binlog消费完后关闭升级，检查参数并恢复连接。使用pt-table-checksum校验数据，避免并发操作与参数不一致导致冲突。

升级多源复制环境需要谨慎操作，确保数据一致性与服务可用性。核心思路是逐步更新节点、验证复制状态，并避免主从冲突。以下是具体步骤和注意事项。

了解多源复制架构

多源复制指多个主库（Master）向一个从库（Slave/Replica）写入数据。常见于分库分表、数据聚合等场景。升级前需确认当前拓扑结构、MySQL 版本兼容性及 GTID 使用情况。

关键点：

• 确认所有主库和从库的 MySQL 版本支持目标版本的复制协议
• 建议先在测试环境模拟升级流程
• 备份所有节点的数据和配置文件

制定升级顺序

推荐先升级从库，再依次升级各主库。这样可降低风险，便于回滚。

操作建议：

• 停止从库的复制线程：STOP SLAVE;
• 升级从库 MySQL 软件并启动新版本
• 检查错误日志，确认无兼容性问题
• 重新启动复制：START SLAVE;
• 监控复制延迟和SHOW SLAVE STATUS中的错误信息

逐个升级主库

每次只升级一个主库，避免并发写入异常。

步骤包括：

• 将应用流量切换到其他主库（如支持）
• 等待该主库的 binlog 被从库完全消费
• 关闭主库，升级 MySQL 版本
• 启动后检查binlog_format、server_id等参数是否正确
• 恢复应用连接，观察从库复制状态

处理 GTID 与复制一致性

若使用 GTID 复制，升级前后必须保证gtid_mode一致。

注意：

• 新版 MySQL 可能默认启用 GTID，需与旧主库保持兼容模式
• 升级后运行SELECT @@GLOBAL.gtid_executed;对比各节点
• 如有断裂，可通过SET GTID_NEXT手动跳过空事务
• 使用pt-table-checksum验证数据一致性

基本上就这些。只要按节点逐步推进，监控到位，多源复制升级可以平稳完成。关键是别同时动多个主库，也别忽略参数差异。不复杂但容易忽略细节。