mysql升级后主从复制出现异常，会导致从库无法同步主库数据，影响读写分离架构的正常运行，需要及时排查并修复问题。常见的异常表现包括从库复制线程停止、同步延迟过大、报错提示版本不兼容或者SQL执行失败等。
常见异常原因
首先我们需要了解升级后主从异常的常见诱因，才能针对性排查：
- mysql版本升级后，部分复制相关的参数默认值发生变化，主从配置不一致导致复制失败
- 新版本废弃了旧版本的某些SQL语法或者函数，主库执行的语句在从库执行时出错
- 升级过程中主从数据出现不一致，比如升级前未停止主从复制导致部分数据未同步
- 复制用户权限在升级后发生变化，从库无法连接主库获取binlog
- binlog格式或者GTID相关配置在新版本下不兼容，导致复制链路无法建立
排查步骤
1. 查看从库复制状态
首先登录从库mysql，执行以下命令查看复制状态：
SHOW SLAVE STATUSG
重点关注Slave_IO_Running和Slave_SQL_Running两个字段，正常情况两者都应该是Yes。如果IO线程不是Yes，说明从库无法连接主库或者无法获取binlog；如果SQL线程不是Yes，说明从库执行同步的SQL时出错。同时记录Last_IO_Error和Last_SQL_Error的报错信息，这是排查问题的关键。
2. 检查主从版本和配置
分别查看主库和从库的版本，确认升级后的版本是否支持当前的复制模式：
SELECT VERSION();
然后对比主从库的复制相关配置，重点检查server-id、log_bin、binlog_format、gtid_mode、enforce_gtid_consistency等参数是否一致，不一致的参数需要调整为统一值。
3. 验证复制用户权限
检查从库使用的复制用户是否具备正确的权限，登录主库执行：
SHOW GRANTS FOR '复制用户名'@'从库IP';
复制用户需要拥有REPLICATION SLAVE和REPLICATION CLIENT权限，如果权限不足，需要重新授权。
4. 检查数据一致性
如果SQL线程报错提示主键冲突、记录不存在等问题，可能是主从数据不一致导致的。可以使用pt-table-checksum工具检查主从数据差异，或者手动对比报错涉及的表数据。
常见问题的处理方法
IO线程异常
如果Last_IO_Error提示无法连接主库，先检查主从网络是否通畅，防火墙是否开放了mysql端口。如果提示binlog文件不存在，可能是主库清理了从库未同步的binlog，需要重新配置主从复制：
-- 从库停止复制 STOP SLAVE; -- 重新配置主库信息，注意修改主库IP、端口、复制用户、密码、主库当前binlog文件和位置 CHANGE MASTER TO MASTER_HOST='主库IP', MASTER_PORT=3306, MASTER_USER='复制用户', MASTER_PASSWORD='复制密码', MASTER_LOG_FILE='主库当前binlog文件名', MASTER_LOG_POS=主库当前binlog位置; -- 启动复制 START SLAVE;
SQL线程异常
如果是SQL执行报错，先根据Last_SQL_Error的提示定位问题SQL。如果是语法不兼容导致的问题，可以临时跳过该错误：
-- 停止复制 STOP SLAVE; -- 跳过1个错误，错误较多时可以调整数值 SET GLOBAL sql_slave_skip_counter=1; -- 启动复制 START SLAVE;
如果是数据不一致导致的错误，需要先修复数据差异，再重新开启复制。如果是GTID模式下的错误，可以使用以下方式跳过：
STOP SLAVE; -- 设置跳过错误的GTID SET GTID_NEXT='错误事务的GTID'; BEGIN;COMMIT; SET GTID_NEXT='AUTOMATIC'; START SLAVE;
配置不兼容问题
如果是参数不一致导致的复制异常，需要将主从库的复制相关参数调整为一致，修改配置文件后重启mysql实例，再重新启动复制线程。如果是binlog格式不兼容，建议统一使用ROW格式的binlog，兼容性更好。
升级规避建议
为了避免升级后出现主从异常，升级前需要做好准备工作：首先备份主从库的所有数据，升级前停止主从复制，确保主从数据完全一致；提前在测试环境验证升级流程，确认复制功能正常；升级后先检查主从配置和复制状态，确认无异常后再恢复业务。