MySQL 8.4/9.7 备份恢复：物理备份别指望跨大版本，工具版本要逐版本对齐
认证插件
MySQL 8.4 已移除 mysql_native_password，MySQL 9.7 同样不再支持，所有备份账号必须使用 caching_sha2_password。老旧的备份客户端不支持该插件时，会直接报认证失败。
系统字典与物理备份的跨版本限制
MySQL 8.4、9.7 使用统一数据字典，物理备份不能跨大版本直接恢复。8.4 的物理备份集不能直接拷贝到 9.7 实例启动，反之亦然。跨版本迁移只能使用逻辑备份。
复制语法
master/slave 关键字已废弃，改为 source/replica。备份集内部记录 binlog 位置信息的字段名称也发生变化，读取这些字段的脚本需要同步适配。
系统变量废弃
expire_logs_days 废弃，统一使用 binlog_expire_logs_seconds。备份脚本、配置文件都要跟着改。
mysqlbackup 版本必须与服务大版本严格匹配
mysqlbackup 8.4 用于 MySQL 8.4，mysqlbackup 9.7 用于 MySQL 9.7，不可混用。
物理备份权限
物理备份账号必须授予 BACKUP_ADMIN 权限，缺少该权限会造成 mysqlbackup 备份失败。
XtraBackup 版本兼容
Percona 文档写明 XtraBackup 8.4 只支持 MySQL 8.4 和 Percona Server for MySQL 8.4，不支持 MySQL 8.0 或 9.x。MySQL 8.0 要看 XtraBackup 8.0 系列的支持范围。生产环境不要用「版本号差不多」判断能不能备份恢复。
mysqlbackup 的两个阶段
- 备份阶段：在线读取 InnoDB 数据页，拷贝数据文件，同时拷贝 myisam、元数据、binlog 信息；记录备份结束时刻的 LSN 日志序列号。
- apply-log 准备阶段：备份得到的数据文件存在未提交事务、脏页，需要执行 apply-log，回放备份期间产生的 redo 日志，把备份集处理成一致性可恢复状态。image 镜像需要先 extract 解压到临时目录再执行 apply-log；directory 目录备份直接对目录执行 apply-log。
跳过 apply-log，备份集就不是一致性可恢复的状态。
GTID 与 PITR
mysqlbackup 备份元数据内部自动记录 GTID 集合。9.7 恢复之后可以直接基于 GTID 做 binlog 回放，不需要手工找 position 位点。
binlog 与 RPO
binlog 保留 30 天不代表 RPO 就一定是几秒。真正能恢复到哪里，取决于最后一份完整、可读、已经复制到独立故障域的 binlog。生产还要看 sync_binlog、innodb_flush_log_at_trx_commit、binlog 归档延迟、归档进程是否断过、binlog 文件链是否连续。MySQL 8.4 默认 sync_binlog=1、innodb_flush_log_at_trx_commit=1，偏向安全；为性能改小持久性保证，就要把可能丢最近事务算进 RPO。
恢复演练步骤（建议每月至少一次）
- 准备一台隔离机器，安装相同大版本的 MySQL。
- 拉取最近一次全量备份和对应 binlog，确认解密密钥、账号、证书和对象存储访问方式都可用。
- 恢复全量备份，记录耗时。
- 回放 binlog 到指定时间点，记录耗时。
- 校验关键库表数量、关键业务 SQL、存储过程、事件、触发器、账号、角色和权限。
- 检查 charset、collation、time_zone、sql_mode、只读开关和网络隔离，确保恢复实例不会被真实业务流量误连。
- 用应用连接恢复实例，跑一组只读冒烟接口。
- 记录实际 RTO、可恢复到的时间点、失败步骤和人工操作。
常见策略
- 业务库主要是 InnoDB、数据量不大：每天
mysqldump --single-transaction --routines --events --triggers --source-data=2全量备份，保留 7 到 30 天，binlog 保留时间覆盖同样窗口。 - 数据量上来以后：每天或每周做一次 XtraBackup 全量备份，按业务写入量决定是否增加增量备份，binlog 单独备份。
- 备份落盘后计算校验和，复制到独立存储；重要业务再保留一份加密、跨账号、带版本或不可变策略的副本。
- 监控最新可用全量备份时间、最新已归档 binlog 时间、binlog 文件连续性和归档进程状态。
- 写一份恢复 runbook，包含负责人、备份位置、解密方式、恢复命令、binlog 起点查找方式、隔离恢复环境、校验 SQL 和回滚说明。
- MySQL 8.4 升级到 9.7 项目：升级前必须同时做一份物理备份 + 一份逻辑备份；逻辑备份作为兜底，防止物理备份跨版本无法恢复。
落地检查项
- 备份账号认证插件为 caching_sha2_password，且备份客户端支持它。
- 跨大版本迁移走逻辑备份，不试图搬运物理备份集。
- mysqlbackup 版本与 MySQL 服务大版本逐版本对齐（8.4 对 8.4，9.7 对 9.7）。
- XtraBackup 版本落在目标实例的支持范围内，不按版本号相近判断。
- 物理备份账号已授予 BACKUP_ADMIN。
- 备份完成后执行 apply-log；image 镜像先 extract 到临时目录再执行。
- 配置文件与备份脚本中没有残留 expire_logs_days，已改用 binlog_expire_logs_seconds。
- 复制相关脚本已从 master/slave 改为 source/replica，涉及备份集内 binlog 位置字段名的代码同步更新。
- 确认 sync_binlog、innodb_flush_log_at_trx_commit 的取值与 RPO 目标一致。
- 监控最新可用全量备份时间、最新已归档 binlog 时间、binlog 文件连续性、归档进程状态。
- 每月至少一次隔离环境恢复演练，记录 RTO、可恢复到的时间点与失败步骤。