先升级从库再逐个升级主库，确保数据一致性。需确认拓扑结构、版本兼容性及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验证数据一致性
基本上就这些。只要按节点逐步推进，监控到位，多源复制升级可以平稳完成。关键是别同时动多个主库，也别忽略参数差异。不复杂但容易忽略细节。
