从库版本不能高于主库一个大版本，因binlog事件解析、gtid处理及系统表结构（如mysql.user从myisam→innodb）跨大版本不兼容，导致sql线程报error 1236或权限校验崩溃。
不能直接升级到高于主库一个大版本的版本，比如主库是 5.7，从库升到 8.4 就会立即复制失败；但若主库是 8.0，从库升到 8.4 是允许且推荐的操作路径。
为什么从库版本不能高于主库一个大版本？
MySQL 复制协议要求主从之间 binlog event 解析、GTID 处理、系统表结构必须兼容。跨大版本（如 5.7 → 8.4）会导致：
-
SHOW SLAVE STATUS中Slave_IO_Running可能为Yes，但Slave_SQL_Running直接报错ERROR 1236 (HY000): Could not parse relay log event entry - 8.4 的 SQL 线程无法识别 5.7 写入的
mysql.user表结构（MyISAM → InnoDB 字典重构），权限校验崩溃 - 5.7 的 binlog_format = MIXED 语句在 8.4 上可能因解析逻辑变更而执行失败，尤其含函数或子查询的 STATEMENT 模式事件
8.0 主库 + 8.4 从库是否可行？
可行，但必须满足三个硬性条件：
- 主库
my.cnf中显式启用双认证插件：default_authentication_plugin=caching_sha2_password且mysql_native_password=ON（仅 8.0.29+ 支持） - 从库配置中加
replica_sql_verify_checksum=OFF，否则 8.0 生成的 binlog checksum 格式与 8.4 默认不兼容，启动即报Got fatal error 1236 - 不要用
mysqldump导出后CHANGE SOURCE TO—— dump 文件里的SET @@GLOBAL.GTID_PURGED是 8.0 格式，8.4 解析失败；应改用mysqlpump或手动修正 GTID 集合
升级后验证什么才算真正“跑通”？
不能只看 Seconds_Behind_Source = 0 或 Replica_IO_Running = Yes。必须确认：
-
SHOW REPLICA STATUS\G中Replica_IO_Running和Replica_SQL_Running均为Yes，且Replica_SQL_Running_State不卡在Reading event from the relay log - 主库写入一条带
JSON_OBJECT()的语句，从库能正确 SELECT 出结果（验证函数兼容性） - 用旧版 JDBC（如 mysql-connector-java:5.1.47）连从库执行
SELECT USER()，不报Access denied for user ''@'localhost'（验证认证插件回退路径）
最易被忽略的是：8.4 从库启动后若没执行 --upgrade=FORCE 或等效的自动字典升级流程，mysql.role_edges 这类新表不存在，后续创建角色就会失败——这个错误不会立刻暴露，但一建账号就崩。
