主从mysql版本不一致必然导致复制出错，不可硬扛；因innodb行格式、系统表结构、权限字段、字符集、sql模式等存在差异，遇ddl或系统表变更时sql线程大概率报1032/1146错误并停止。
主从 MySQL 版本不一致时，复制必然出错，不能硬扛
MySQL 主从版本不一致（比如主库是 8.0.34，从库是 5.7.42 或 8.4.0）不是“可能不一致”，而是“一定会出问题”。InnoDB 行格式、系统表结构（mysql.user、mysql.role_edges）、权限字段、默认字符集、SQL 模式解析逻辑等都存在差异。一旦遇到 DDL 或涉及系统表的变更（如 CREATE USER、ALTER TABLE ... ENCRYPTION），从库 SQL 线程大概率报 Error_code: 1032、Error_code: 1146 或直接停在 Slave_SQL_Running: No。
如何快速确认是不是版本不一致导致的复制中断
登录从库执行 SHOW SLAVE STATUS\G，重点看三处：
-
Last_SQL_Error中是否含 “Table ‘mysql.xxx’ doesn’t exist”、“Unknown column ‘xxx’ in ‘field list’”、“Unsupported engine” 等提示 —— 这是典型系统表结构不兼容信号 -
Replicate_Ignore_DB或Replicate_Wild_Ignore_Table是否被误设为mysql—— 若忽略系统库，后续权限变更就永远不会同步 - 对比主从的
SELECT VERSION(), @@sql_mode, @@default_authentication_plugin输出 —— 即使都是 8.0，小版本差 3+ 也可能因修复补丁缺失导致行为不一致
修复必须分两步：先停写、再升/降级，不能用 pt-table-sync
pt-table-sync 对系统库完全无效，它只处理用户数据库中的表数据，且依赖主从表结构严格一致。系统库（mysql、performance_schema、information_schema）无法校验、不可覆盖、也不该手动改。真正可行路径只有：
- 若从库版本 低于 主库（如主 8.0.34 → 从 5.7.42）：必须升级从库到与主库 同大版本、同小版本号（至少 8.0.34），升级前需做完整备份 +
mysqldump --no-data --databases mysql备份原系统库结构 - 若从库版本 高于 主库（如主 8.0.30 → 从 8.4.0）：极大概率不兼容，官方不支持反向兼容；应降级从库或更换为同版本，不要尝试跳过错误，因为高版本新增字段（如
mysql.user.authentication_string的加密方式变更）会导致后续所有用户操作失败 - 无论升/降级，操作后必须执行
mysql_upgrade（MySQL 8.0.16+ 已弃用，改用mysqld --upgrade=FORCE）并重启 mysqld，否则mysql库元数据不会更新
重做从库时，系统库初始化最容易被忽略的细节
用 mysqldump --all-databases 全量重建从库时，默认不会导出 mysql 库（除非显式加 --databases mysql），而 --master-data=2 生成的 CHANGE MASTER TO 语句也只作用于用户库。真正安全的做法是：
- 主库上执行：
mysqldump -u root -p --no-create-info --skip-triggers --compact --databases mysql > mysql_system.sql（仅导出数据，不带建表语句） - 从库初始化后，先导入该
mysql_system.sql，再执行FLUSH PRIVILEGES;，最后才启动复制 - 验证：在从库查
SELECT COUNT(*) FROM mysql.user;和主库比对；执行SELECT User, Host FROM mysql.user WHERE authentication_string = ''，确认空密码用户未被意外清除
系统库不是普通数据，它的不一致不会立刻报错，但会在某次权限变更、SSL 配置或插件加载时突然爆发 —— 到那时，连管理员都可能被锁在库外。
