首先确认从库复制线程状态，使用SHOW REPLICA STATUS\G检查Replica_IO_Running和Replica_SQL_Running是否为Yes，Seconds_Behind_Master延迟是否正常，Last_Error有无报错；接着查看错误日志定位异常，重点关注升级后兼容性、GTID配置或中继日志问题；然后验证GTID模式一致性，确保主从gtid_mode和enforce_gtid_consistency配置匹配，并核对received_transaction_set；最后对比主库SHOW MASTER STATUS与从库Relay_Master_Log_File和Exec_Master_Log_Pos位置，确认同步点接近且无滞后。
MySQL升级后检查复制状态，重点是确认主从复制是否正常运行、有无延迟、线程是否启动以及错误日志中是否有异常。以下是具体操作步骤和关键命令。
1. 登录从库并查看复制线程状态
连接到从库的MySQL实例，执行以下命令查看复制的基本状态：
SHOW SLAVE STATUS\G或在 MySQL 8.0+ 推荐使用：
SHOW REPLICA STATUS\G注意：MySQL 8.0.22 开始，SLAVE 相关术语被 REPLICA 替代，命令可能需要调整。
关注以下关键字段：
- Slave_IO_Running 或 Replica_IO_Running：应为 Yes，表示I/O线程正在读取主库的binlog。
- Slave_SQL_Running 或 Replica_SQL_Running：应为 Yes，表示SQL线程正在应用中继日志。
- Seconds_Behind_Master：显示复制延迟秒数，正常情况下应为 0 或较小值，若为 NULL 可能表示复制中断。
- Last_Error 或 Last_IO_Error / Last_SQL_Error：如果有错误，会在这里显示具体信息，需重点关注。
2. 检查错误日志
如果复制线程未运行或出现错误，查看MySQL错误日志定位问题：
-- 查看日志路径 SELECT @@log_error;-- 然后在系统中查看该文件 tail -f /var/log/mysql/error.log
升级后常见问题包括：兼容性问题、GTID设置变更、relay log或master info文件损坏等，错误日志通常会给出明确提示。
3. 验证GTID设置（如启用）
如果使用GTID复制，需确保主从GTID配置一致：
-- 检查是否开启GTID SELECT @@gtid_mode, @@enforce_gtid_consistency;-- 查看从库接收到的事务
SELECT RECEIVED_T
RANSACTION_SET FROM performance_schema.replication_connection_status;
升级后可能出现GTID集合不连续或冲突，导致复制停止。必要时可使用 SET GTID_NEXT 跳过特定事务（谨慎操作）。
4. 确认主库binlog位置与从库同步点
对比主库当前binlog位置和从库读取的位置，确认一致性：
-- 在主库执行 SHOW MASTER STATUS;-- 在从库执行 SHOW SLAVE STATUS\G -- 查看 Relay_Master_Log_File 和 Exec_Master_Log_Pos 是否与主库接近
若差距过大且 Seconds_Behind_Master 不更新，可能是SQL线程卡住。
基本上就这些。升级后务必逐项检查复制状态，确保各线程运行正常、无错误、延迟可控。发现问题及时处理，避免数据不一致。
