先升级从库再升级主库，确保复制兼容性与数据一致性。1. 检查拓扑及版本兼容性，确认binlog格式与GTID支持；2. 备份主从数据并记录复制位置；3. 停止从库服务，升级MySQL版本并执行mysql_upgrade，重启复制后验证状态；4. 所有从库升级完成后，可选切换主从角色，将已升级从库提升为主库，原主库降级后升级；5. 升级后持续监控复制延迟、GTID连续性及应用连接，确保Seconds_Behind_Master为0且无错误日志。
MySQL升级复制环境需要谨慎操作，确保主从数据一致性的同时，避免服务中断。整个过程需按步骤进行，尤其注意版本兼容性与复制格式的匹配。
1. 检查当前复制架构与版本兼容性
确认当前MySQL主从拓扑结构（如一主多从、级联复制等），并查阅官方文档确认新旧版本之间的复制兼容性。
- 主库和从库的MySQL版本应遵循“从库版本不低于主库”的原则
- 若跨大版本升级（如5.7 → 8.0），需检查是否支持GTID、复制协议变更等
- 确认binlog格式（ROW、STATEMENT、MIXED）是否一致且适用于新版本
2. 备份所有节点数据
在任何升级前，对主库和从库执行完整备份，防止升级失败导致数据丢失。
- 使用mysqldump或物理备份工具（如Percona XtraBackup）
- 记录主库当前binlog位置（SHOW MASTER STATUS）
- 保存从库复制信息（SHOW SLAVE STATUS）
3. 先升级从库
建议先对从库进行升级，验证复制在新版本下是否正常运行。
- 停止从库：STOP SLAVE;
- 关闭MySQL服务，替换二进制文件或使用包管理器升级
- 启动新版本MySQL，并运行mysql_upgrade（8.0后自动执行）
- 重启复制：START SLAVE;
- 检查复制状态：SHOW SLAVE STATUS，确认无错误
4. 升级主库并切换角色（可选）
当所有从库升级完成后，再升级主库。为降低风险，可考虑临时切换主从角色。
- 将一个已升级的从库提升为主库（执行STOP SLAVE, RESET SLAVE）
- 原主库降为从库，完成升级后再重新加入集群
- 若不切换，则直接升级原主库：停服务 → 升级 → 启动 → 执行mysql_upgrade
5. 验证复制与应用连接
升级完成后，持续监控复制延迟、错误日志及应用程序访问情况。
- 检查SHOW REPLICA STATUS（8.0+）或SHOW SLAVE STATUS中的Seconds_Behind_Master
- 确认GTID是否连续（若启用）
- 测试写入主库后能否正确同步到所有从库
- 更新应用连接配置（如有必要）
