延迟从库仅适用于同版本主从复制，无法用于跨版本回滚迁移；因其依赖binlog格式、系统表结构、InnoDB字典等完全兼容，MySQL 8.0与5.7间启动复制即报错，跨版本回滚唯一合规路径是还原升级前的逻辑或物理备份。
延迟从库不能用于跨版本数据回滚迁移——它只在同版本主从间生效，且不改变MySQL实例本身的版本。
延迟从库的适用前提：必须同版本
延迟从库本质是复制机制的时序控制，依赖主从两端的binlog解析、SQL执行、InnoDB字典结构完全兼容。一旦主库是MySQL 8.0、从库是5.7，START REPLICA会直接失败，报错类似ERROR 1236 (HY000): Could not parse relay log event entry或Unknown table engine 'InnoDB'。这是因为：
- MySQL 8.0 的 binlog event format（如新增的
WRITE_ROWS_EVENT_V2）5.7 无法识别 - 系统表结构（
mysql.role_edges、mysql.global_grants等）在5.7中根本不存在 - InnoDB redo log 版本、数据页格式、元数据存储方式均不向下兼容
误以为“延迟从库能跨版本”常踩的坑
有人试图先在8.0主库上建一个5.7延迟从库，等出事后“切过去用”，结果发现：
- 从库启动即报错：
Table 'mysql.gtid_executed' doesn't exist（5.7无GTID表） - 即使跳过系统库复制，业务库同步也会卡在
CREATE TABLE ... ENCRYPTION='Y'（8.0默认加密，5.7不支持） -
CHANGEREPLICATIONSOURCETOSOURCE_DELAY=3600命令本身在5.7中不存在，语法报错 - 即便强行绕过启动，SQL线程一碰到
JSON_CONTAINS或CAST(... AS JSON)就崩溃退出
真正可行的跨版本回滚路径只有两条
如果已升级到MySQL 8.0但想退回5.7，唯一合规做法是还原升级前的备份，而非依赖任何从库：
- 用升级前的
mysqldump --single-transaction --routines --events --triggers导出文件，在干净的MySQL 5.7实例上导入 - 若当时做了XtraBackup物理备份，必须用XtraBackup 2.4（非8.0版）恢复到5.7环境；XtraBackup 8.0备份不可降级使用
- 导入前手动处理不兼容项：替换
caching_sha2_password为mysql_native_password，删掉ROLE相关语句，改写TIMESTAMP字段默认值
延迟从库该放在哪一级做应急预案
它只应在同版本高可用体系内部署，比如：
- 所有生产节点统一为MySQL 8.0.33 → 配一台
SOURCE_DELAY=3600的8.0.33延迟从库 - 测试环境用5.7.40 → 单独配一台5.7.40延迟从库，仅用于该环境误操作兜底
- 跨版本迁移窗口期，可临时启用双写+校验，但延迟从库不参与版本切换逻辑
把延迟从库当成“跨版本时光机”，等于把数据库当成了时间机器+版本转换器——它既不是前者，也不能做后者。真正容易被忽略的是：延迟配置本身不具备版本翻译能力，它只是让同一套引擎多等几秒再跑。
