mysql 8.0.20起redo log格式升级为v4，因undo表空间id从1字节扩至4字节导致日志结构变更，旧版xtrabackup（如8.0.11）不兼容而报错unknown redo log format (4)。
MySQL 8.0.20 起 redo log 格式升级为 v4，旧版 XtraBackup（如 8.0.11）无法识别，报错 Unknown redo log format (4) 是必然结果，不是配置问题，而是二进制不兼容。
为什么 MySQL 8.0 改了 redo log 格式
根本原因是 undo 表空间 ID 值扩展：MySQL 8.0 将 undo 表空间 ID 从 1 字节扩大到 4 字节，导致所有涉及 undo 的 redo 记录（如 MLOG_UNDO_INSERT、MLOG_UNDO_ERASE_END）必须多存 3 字节。这直接抬高了写 I/O 压力——官方实测写密集型负载性能下降约 10%。
为抵消这部分开销，MySQL 团队在 8.0.20 引入了新的 redo log 格式（v4），核心优化包括：
- 压缩 undo 相关日志字段的编码方式，避免冗余填充
- 合并连续的小修改为单条紧凑记录（例如多个
mlog_1byte合并） - 移除部分已废弃的旧字段保留位
这些改动不改变语义，但改变了磁盘上字节布局，因此版本号升至 4。
如何确认当前实例的 redo log 格式版本
MySQL 本身不提供直接查格式版本的 SQL 函数，但可通过以下方式交叉验证：
- 查 MySQL 版本：
SELECT VERSION();—— 若 ≥8.0.20，格式必为 v4 - 看错误日志启动阶段输出：
InnoDB: Redo log format version 4（明确出现即确认） - 检查
#innodb_redo目录下文件头（需 hexdump）：xxd -l 64 /var/lib/mysql/#innodb_redo/ib_redo0，v4 文件头第 12 字节为0x04
注意：SHOW VARIABLES LIKE 'innodb_log%' 类命令在 8.0.30+ 已不显示格式信息，因参数体系已转向 innodb_redo_log_capacity。
XtraBackup 兼容性与应对方案
报错 Unknown redo log format (4) 意味着你正在用不支持 v4 的备份工具连接 8.0.20+ 实例。官方明确要求：
- XtraBackup 8.0.12+ 才开始支持 redo log v4
- Percona XtraBackup 8.0.30 对应 MySQL 8.0.30 的动态 redo log 管理（
innodb_redo_log_capacity） - 若混用低版本 XtraBackup 和高版本 MySQL，即使跳过 --no-lock，仍会在读取 redo 文件时失败
临时绕过方法只有两个且均有风险：
- 降级 MySQL 到 8.0.19（不推荐，放弃安全更新和新特性）
- 改用
mysqldump+FLUSH TABLES WITH READ LOCK（仅适用于小库，锁表时间长）
没有“打补丁”或“配置开关”能让旧版 XtraBackup 读懂 v4 —— 这是底层序列化协议变更，不是开关控制项。
动态调整 redo log 容量时格式是否受影响
否。innodb_redo_log_capacity（MySQL 8.0.30+）只控制总空间大小和后台文件管理逻辑，不触碰单个 redo record 的二进制结构。v4 格式定义的是每条日志的字段排列、长度和编码规则，与文件数量（固定 32 个）、命名方式（ib_redo$SEQ）、回收策略（_tmp 文件）完全正交。
也就是说：你可以安全地执行 SET GLOBAL innodb_redo_log_capacity = 2G;，只要 XtraBackup 版本匹配，备份不会因容量调整而失败。但若 XtraBackup 不认 v4，再小的容量也照样报错。
真正容易被忽略的是：很多运维脚本仍硬编码检查 innodb_log_file_size，而在 8.0.30+ 这个变量已被弃用且返回 NULL —— 依赖它的监控或备份前置校验会静默失效。
