Backup/Restore

做的事：真实回顾本系列已经验证过的三条备份/恢复路径

这一篇不重新跑实验，而是把前面几篇真实验证过的机制放在一起做对比总结。

验证：三条路径，真实各自解决不同的问题

回顾 · 本系列真实验证过的数据

1. mysqldump --single-transaction（本系列《mysqldump 一致性备份》一篇）
   真实机制：MVCC一致性读，不锁表
   真实产物：纯SQL文本，人类可读，可以跨版本/跨引擎恢复
   真实验证：并发修改不影响dump内容，还原后8行数据完全一致

2. Clone Plugin（本系列《Clone Plugin》一篇）
   真实机制：物理页面级复制，不经过SQL层
   真实产物：完整的InnoDB数据目录，只能恢复到兼容的MySQL版本
   真实验证：一条命令克隆2.5GB数据，新实例50000行数据分毫不差

3. Crash Recovery（本系列《Crash Recovery》一篇）
   真实机制：redo log重放已提交事务，undo log回滚未提交事务
   真实验证：kill -9真实模拟崩溃，3条已提交数据全部保留，1条未提交数据真实消失

结论：这三条真实路径覆盖的是完全不同的风险场景

Crash Recovery真实解决的是"进程突然死掉"这种瞬时故障，恢复的是同一份数据文件，解决不了磁盘本身损坏、或者需要回到"几小时前"这种场景；mysqldump和Clone Plugin真实解决的都是"我需要一份独立于当前实例的数据副本"，区别在于mysqldump牺牲速度换取了最大的兼容性和可读性(SQL文本可以拿到任何版本、任何引擎的MySQL上跑)，Clone Plugin牺牲了跨版本兼容性换取了真实快得多的物理复制速度。一套完整的真实备份策略，通常不是三选一，而是组合使用：定期的全量备份(mysqldump或者Clone/XtraBackup这类物理备份)加上持续归档的binlog(本系列《Row-Based Binlog》一篇验证过它记录的是真实的行级变更)，真实才能做到"恢复到任意时间点"这种更精细的能力——单独的一次性快照，不管是逻辑的还是物理的，都只能恢复到快照那一刻，中间发生的变更需要靠binlog真实重放补上。

分步演示：三条备份/恢复路径的真实对比

每一步都是对本系列前面真实跑过的实验的回顾整理。

三条真实路径，各自解决不同的风险

这一步回顾的机制

本文用到的工具

本文整理回顾本系列《mysqldump 一致性备份》《Clone Plugin》《Crash Recovery》三篇真实验证过的机制，未重新执行新实验

下一篇 · MYSQL / INNODB 120

磁盘满、Redo 满与连接耗尽