在线备份恢复演练怎么做：校验数据而不只看命令成功

在线备份恢复演练不能只看 mysqldump 和 mysql 返回 0。可靠的做法是把演练拆成“源库基线、可控转储、隔离恢复、数据比对、对象检查”五层证据：命令成功只说明 SQL 文件被执行，只有关键数据和业务不变量也对得上，备份才有恢复价值。

官方资料：https://dev.mysql.com/doc/refman/8.4/en/

如果业务表是 InnoDB，可用 --single-transaction 获取一致性快照；恢复到隔离实例后，至少同时校验行数、主键范围、业务聚合值和触发器/存储程序等对象。非 InnoDB 表和演练期间的 DDL 需要单独处理。

• 先留基线：记录关键表的数量、主键范围和业务汇总值。
• 再做恢复：显式包含 routines、events、triggers，并把输出导入隔离实例。
• 最后放行：数据层、对象层和业务层都通过，才记录为可用备份。

先划定边界，再保存源库基线

演练前列出数据库、表和附属对象，不要默认一个 SQL 文件会覆盖全部运行依赖。MySQL 8.4 的 mysqldump 需要显式使用 --routines 和 --events 才会导出存储程序与事件；触发器默认会随表导出，但仍应在恢复后核对。

基线不必保存业务明文，可以只保存脱敏后的比较结果。例如订单表关注行数、最小和最大订单号、金额合计；字典表关注主键集合；审计表关注最近一段时间的数量。这样既能发现“导入成功但少了一批数据”，也不会把客户信息复制进演练记录。

用 mysqldump 生成可解释的在线快照

# 仅对主要为 InnoDB 的业务库做一致性快照
mysqldump \
  --single-transaction \
  --quick \
  --routines \
  --events \
  --triggers \
  --hex-blob \
  --databases appdb \
  > appdb-restore-drill.sql

# 计算文件摘要，确认传输到恢复环境的文件没有被替换
sha256sum appdb-restore-drill.sql > appdb-restore-drill.sql.sha256

--single-transaction 会以 REPEATABLE READ 开始事务，对 InnoDB 表取得开始时刻的一致状态，并且不需要在整个导出期间锁住业务表。它不是所有引擎的万能开关：MyISAM、MEMORY 等非事务表仍可能变化，演练期间对被导出表执行 ALTER TABLE、DROP TABLE、TRUNCATE TABLE 等 DDL 也可能破坏一致性。若要配合时间点恢复，还应结合 --source-data 管理二进制日志坐标。

恢复实例里先查对象，再查数据

恢复环境应与生产隔离，账号权限和字符集尽量接近目标环境。导入命令本身只证明解析和执行过程没有报错：

# 在空的隔离数据库中导入，不把演练写回生产库
mysql --host=restore-db --user=drill_user --password appdb \
  

对事件可以查询 information_schema.EVENTS，对存储函数和过程可使用 SHOW CREATE 比较定义摘要。对象缺失时不要用“表数据都在”来掩盖，它往往会在下一个定时任务或写入动作发生时才暴露。

对象清单和恢复实例之间的关系如下图所示。它把“文件存在”“对象存在”“数据一致”分开，避免把一个通过条件误当成整场演练通过。

用多层校验判断恢复是否真的可用

第一层是结构校验：关键表数量、字段类型、索引、触发器、过程、函数和事件都要在清单中出现。第二层是数据校验：对源库和恢复实例执行相同的统计查询。

-- 用稳定的业务字段做比对，避免把客户明文写进演练记录
SELECT
  COUNT(*) AS row_count,
  MIN(order_id) AS first_id,
  MAX(order_id) AS last_id,
  COALESCE(SUM(total_amount), 0) AS amount_sum
FROM orders;

-- CHECKSUM TABLE 可作为辅助证据，但跨版本或存储格式变化时要谨慎解释
CHECKSUM TABLE orders;

CHECKSUM TABLE 可以比较备份前后的表内容，但官方也提示存储格式变化可能造成校验值变化，所以它不能取代业务查询。第三层是抽样校验：按主键首段、最近一天和大金额订单各取少量脱敏字段，确认边界记录没有错位。第四层是业务不变量，例如订单金额合计、有效用户数、外键关联数量应符合基线。

把差异和放行条件写进演练记录

记录备份文件摘要、源库版本、恢复实例版本、导入耗时、对象差异、每项比对结果和操作者。恢复实例只要出现行数不一致、关键聚合值不一致、对象缺失或抽样记录不符，就标记为失败并保留证据，不要通过手工补数据把演练“修绿”。

最终结论建议分为“可恢复”“需修复后重演”“不具备恢复证据”三档。下一次演练只复用检查清单，不复用未经解释的成功状态。这样在线备份才从一个命令文件变成了可以被验证、复盘和改进的恢复能力。

常见问题

只有 InnoDB 才能使用在线一致性备份吗？ --single-transaction 的一致性保证针对事务表，MyISAM、MEMORY 等非事务表需要额外锁定或单独安排静态窗口。

导入没有报错还要检查什么？ 至少检查对象清单、关键表统计、抽样记录和业务聚合值；导入成功不等于内容完整。