MySQL 8.4升级后主从复制中断大概率由版本不兼容引发，须通过SHOW SLAVE STATUS\G查Last_SQL_Error、Replicate_Ignore_DB及版本/SQL模式等三项确认；主低从高或主高从低均需升/降级至完全一致小版本并执行mysqld --upgrade=FORCE，严禁跳过错误。
MySQL 8.4 升级后主从复制中断，大概率是版本不兼容导致的系统库结构或 SQL 行为差异，不能靠跳过错误硬扛，必须先确认是否真丢了数据，再决定升/降级或重建。
怎么看是不是版本不兼容导致的复制中断
登录从库执行 SHOW SLAVE STATUS\G，重点检查三项：
-
Last_SQL_Error是否含Table 'mysql.user' doesn't exist、Unknown column 'password_expired'、Unsupported engine 'InnoDB'等字样——这是系统表字段或引擎不匹配的典型信号 -
Replicate_Ignore_DB是否被误设为mysql——忽略系统库会导致权限变更永远不同步 - 执行
SELECT VERSION(), @@sql_mode, @@default_authentication_plugin，对比主从输出：即使都是 8.4，小版本差 2 以上（如主 8.4.3 vs 从 8.4.1）也可能因修复补丁缺失引发解析失败
主库 8.4 → 从库低于 8.4（比如 8.0 或 5.7）
这种情况必须升级从库，不能跳过错误。低版本无法识别 8.4 新增字段（如 mysql.user.password_last_changed）、新认证插件（caching_sha2_password 默认行为变化）、或新行格式（DYNAMIC 表默认压缩逻辑）。
- 先停写主库，做完整备份：
mysqldump --no-data --databases mysql > mysql_struct_backup.sql - 升级从库到与主库完全一致的小版本（如都为 8.4.5），过程中用
mysqld --upgrade=FORCE替代已弃用的mysql_upgrade - 重启后检查
mysql库元数据是否更新：SHOW CREATE TABLE mysql.user对比主从字段数和类型
主库 8.4 → 从库高于 8.4（比如 8.5 或 9.6.0）
官方不支持反向兼容。高版本从库会拒绝执行主库发来的、它认为“过时”的 DDL（例如未带 ALGORITHM=INSTANT 的 ADD COLUMN），或因新约束校验失败而停在 Slave_SQL_Running: No。
- 不要尝试
SET GLOBAL sql_slave_skip_counter = 1—— 这类错误不可逆，跳过只会让后续所有用户登录失败 - 唯一安全路径是降级从库到与主库同版本，或换一台干净机器重搭
- 若已启用 GTID，降级前必须导出并记录当前
gtid_executed，重配时用SET GLOBAL gtid_purged = '...'手动对齐，否则START SLAVE会报GTID_PURGED contains transactions not present in binlog
恢复后必须验证的三个点
启动复制不等于恢复成功：
- 确认
Slave_IO_Running和Slave_SQL_Running都是Yes，且Seconds_Behind_Master在下降而非卡在NULL - 抽样比对关键系统表：
SELECT COUNT(*), MD5(GROUP_CONCAT(host,user)) FROM mysql.user;主从结果必须一致 - 检查
SELECT * FROM performance_schema.replication_applier_status_by_coordinator;中APPLIED_TRANSACTION字段是否持续更新，避免“假运行”
最易被忽略的是：升级后首次启动复制时，read_only 可能被重置为 OFF，务必手动确认并设回 ON，否则从库写入会污染数据一致性。
