MySQL升级可能影响主从复制，须确保从库版本≥主库版本，跨大版本需先升从库再升主库，并检查binlog_format、gtid_mode、sql_mode等配置一致性。
MySQL升级确实可能影响主从复制，关键看主库和从库的版本是否兼容。官方明确要求：从库版本不能低于主库版本，否则容易出现SQL线程报错、数据不一致甚至复制中断。
主从版本兼容的基本原则
MySQL官方推荐主从使用相同大版本（如都是8.0.x），至少保证从库版本 ≥ 主库版本。跨大版本升级（如5.7 → 8.0）必须主从分步升级，且必须先升级从库，再升级主库，否则高概率触发复制失败。
- 5.7主库 + 8.0从库：支持，但需关闭binlog_checksum = NONE或确保主库开启binlog_checksum=CRC32（5.7.5+默认开启）
- 8.0主库 + 5.7从库：不支持，8.0默认使用transaction_write_set_extraction = XXHASH64，5.7无法解析新GTID格式和writeset信息
- 同为8.0.x时，小版本倒退（如8.0.33主库 + 8.0.23从库）也存在风险，部分新特性生成的事件旧从库无法识别
升级前必须检查的复制相关配置
版本兼容只是基础，以下配置不匹配也会导致升级后复制异常：
- binlog_format：主从必须一致（推荐ROW），STATEMENT模式在8.0中限制更多，混合模式易出错
- gtid_mode：主从都启用GTID时，必须同时设置enforce_gtid_consistency = ON，否则升级后启动复制会拒绝
- sql_mode：主从差异可能导致INSERT/UPDATE语句在从库执行失败（如STRICT_TRANS_TABLES开关不一致）
- character_set_server / collation_server：字符集不一致可能引发比较错误或复制跳过
安全升级主从的实操步骤
以5.7 → 8.0升级为例，标准流程如下：
- 确认所有从库已同步到最新位点（Seconds_Behind_Master = 0），并停止SQL线程
- 逐台停用从库，备份配置文件与数据目录，安装8.0二进制包，初始化后用mysqld --upgrade升级系统表
- 启动从库，检查错误日志无“unknown variable”或“unsupported binlog event”类报错，再启动SQL线程
- 全部从库稳定运行24小时以上，确认复制延迟、数据一致性、慢查询无异常，再对主库执行同样升级流程
- 升级完成后，验证SHOW SLAVE STATUS\G中Retrieved_Gtid_Set和Executed_Gtid_Set连续无缺口
常见升级后复制故障及快速定位
升级后复制中断，优先查这三处：
- SHOW SLAVE STATUS\G中的Last_IO_Error或Last_SQL_Error——直接指出是网络、权限、还是SQL解析失败
- 错误日志里是否有Unknown system variable（如old_passwords）、Unsupported binlog format等关键词
- 执行mysqlbinlog --base64-output=decode-rows -v解析主库最新binlog，确认事件类型（如XID、WRITE_ROWS_EVENT_V2）是否被从库支持
