应用一致性备份是什么
应用一致性备份在取数据前先让应用进入可静默状态：冻结写入、把内存中的脏数据刷到磁盘、完成检查点，必要时把事务日志与数据文件对齐到同一时间点。恢复后数据库能直接打开而不必长时间重放日志。与之相对的是崩溃一致性副本，恢复时还要走一遍自身的崩溃恢复流程。
基本信息
| 常用手段 | 应用静默接口、检查点、快照钩子脚本、备份模式锁、事务日志配合 |
|---|---|
| 典型案例 | MySQL LOCK INSTANCE FOR BACKUP、PostgreSQL 备份模式、SQL Server 备份 API、Windows VSS 编写器 |
| 适用对象 | 运行中的数据库、消息队列、邮件系统等有内存缓冲的服务 |
| 权限要求 | 需要应用的备份专用权限或数据库超级用户权限 |
典型使用场景
- 数据库在线备份：备份期间业务不中断，但副本必须可直接起库
- 存储快照前的静默：让快照落在事务边界上，避免起库重放耗时过长
- 多云或跨区复制：源端应用进入静默后取副本，减少远端起库失败概率
- 虚拟机备份：虚拟机内应用静默 + 卷级快照，恢复后应用直接可用
- 重大变更前留底：变更窗口前做一份应用一致副本，回退时快速回滚
MySQL 应用一致快照流程（示意）
MySQL 应用一致快照流程（示意）
# 1) 非事务引擎或需要位点信息时，先加全局读锁并记录位点
mysql -e "FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS;"
# 2) 触发存储快照，或让备份工具读取快照数据目录
# 3) 快照完成立刻释放锁，缩短业务写入阻塞时间
mysql -e "UNLOCK TABLES;"
# 4) 纯 InnoDB 场景可用备份锁替代读锁：不阻塞事务提交
mysql -e "LOCK INSTANCE FOR BACKUP;" # 完成后 UNLOCK INSTANCE三类一致性对照
| 类型 | 恢复后状态 | 要做的额外动作 |
|---|---|---|
| 崩溃一致性 | 文件系统可挂载，应用数据可能有半个事务 | 起库时执行应用自身的崩溃恢复，耗时不可控 |
| 应用一致性 | 事务边界上的完整状态，可直接使用 | 备份前需执行静默/检查点，占用短暂窗口 |
| 逻辑一致性导出 | SQL 或逻辑副本，与物理结构解耦 | 导出与恢复都慢，适合中小数据量与跨版本迁移 |
MySQL 8.0 中纯 InnoDB 场景可用 mysqldump --single-transaction 做逻辑一致性导出；物理快照通常推荐 LOCK INSTANCE FOR BACKUP（不阻塞 DML，只挡 DDL 与部分管理操作）或配合停写窗口。
静默窗口是有代价的：锁或检查点期间写入被阻塞，必须控制快照耗时并在完成后立即释放，且脚本要有异常路径下的解锁收尾。