先升级从库再升级主库，通过监控Seconds_Behind_Master等指标和调整slave_parallel_workers等方式控制复制延迟，确保升级平稳。
在MySQL升级过程中，复制延迟是一个常见且需要重点关注的问题。升级操作可能引起主从架构中的性能波动，导致从库无法及时追上主库的更新。为避免服务中断或数据不一致，必须采取有效策略来应对和缓解复制延迟。
监控复制状态
在升级前和升级过程中，持续监控主从复制的状态是关键。通过以下命令查看从库的延迟情况：
SHOW SLAVE STATUS\G重点关注以下几个字段：
- Seconds_Behind_Master：反映从库落后主库的时间（秒），若值持续增大，说明存在延迟。
- Slave_IO_Running 和 Slave_SQL_Running：确保两者都为“Yes”，否则复制已中断。
- Exec_Master_Log_Pos 与 Read_Master_Log_Pos 的差距：差距越大，积压的中继日志越多。
建议在升级期间使用自动化监控工具（如Prometheus + Grafana、Zabbix）实时跟踪这些指标。
优化升级操作顺序
为减少对复制的影响，应遵循合理的升级顺序：
- 先升级从库，再升级主库。这样可以在不影响写入的情况下完成从库的版本更新。
- 每次只升级一个实例，观察一段时间（如30分钟到1小时），确认无异常后再继续。
- 确保新版本兼容当前的binlog格式和复制协议。例如，MySQL 5.7升至8.0时需注意GTID和系统表的变化。
升级后检查从库是否能正常接收并应用主库的变更，避免因版本不兼容导致SQL线程停止。
提升从库回放能力
如果升级后出现明显延迟，可通过以下方式加快从库追平速度：
- 调整 slave_parallel_workers 参数，启用多线程复制。对于表级并行或逻辑时钟并行（如DATABASE或LOGICAL_CLOCK），合理设置并发数可显著提升应用速度。
- 确认 slave_parallel_type 设置为适合工作负载的模式（推荐 LOGICAL_CLOCK）。
- 避免在从库执行大查询或备份任务，以免影响SQL线程性能。
- 必要时暂停非关键业务读取，释放资源给复制线程。
注意：增加并行度会提高CPU和I/O压力，需结合硬件能力调整。
处理升级后的复制错误
升级可能导致从库报错停止，如不兼容的数据类型、系统表结构变化等。此时应：
- 查看错误日志和 Last_Error 字段，定位具体问题。
- 对于可忽略的临时错误，可使用 STOP SLAVE; SET GLOBAL sql_slave_skip_counter=1; START SLAVE; 跳过单个事件（谨慎使用）。
- 若涉及GTID一致性问题，考虑使用 gtid_purged 手动修复或重建从库。
- 当无法修复时，建议重新搭建从库，通过物理备份（如Percona XtraBackup）快速恢复一致性副本。
基本上就这些。只要提前规划、逐步操作、密切监控，就能在MySQL升级过程中有效控制复制延迟，保障系统平稳过渡。
