数据库备份一致性手段
备份要做到『逻辑自洽』：恢复出来的库必须像某个瞬间的完整状态，而不是一堆前后错位的页和日志。手段按停机预算和存储引擎选：短时间停写最简单，事务引擎用自身的一致性读机制，文件系统冻结解决多卷跨盘快照的时间点对齐问题，最终目标是拿到一个可直接起库的应用一致副本。
基本信息
| 适用平台 | MySQL / PostgreSQL / SQL Server / MongoDB 等；fsfreeze 为 Linux 工具 |
|---|---|
| 停机预算 | 从『零停机 + 事务快照』到『分钟级停写』按业务容忍度选择 |
| 权限要求 | FLUSH TABLES WITH READ LOCK 需 RELOAD 权限；fsfreeze 需 root |
| 落地关键 | 备份与位点记录必须原子：先锁、再记位点、再复制或快照 |
典型使用场景
- 纯 InnoDB 库零停机逻辑导出：单事务一致性快照，不阻塞写入
- 混合引擎（InnoDB + MyISAM）备份：MyISAM 无事务，必须加全局读锁
- 存储快照配合数据库：先锁或先冻结再触发快照，消除多卷时间点错位
- 虚拟机/容器镜像备份：进入静默状态后再做块级快照
- 灾难恢复前的最后一份干净副本：确认一致性再异地复制
MySQL 全局读锁（非事务引擎场景）
MySQL 全局读锁（非事务引擎场景）
# 获取全局读锁，期间业务写入阻塞
FLUSH TABLES WITH READ LOCK;
# 记录二进制日志位点，供后续增量补齐
SHOW MASTER STATUS;
# 保持锁的同时做文件拷贝或触发存储快照
# 快照触发完成后立即释放，恢复业务写入
UNLOCK TABLES;文件系统冻结（多卷一致性）
文件系统冻结（多卷一致性）
fsfreeze -f /data # 冻结文件系统，写入挂起
# 在冻结窗口内触发存储快照（应为秒级完成）
fsfreeze -u /data # 快照返回后立刻解冻
# 校验是否所有挂载点都已解冻
mount | grep -w frozen四种手段对照
| 手段 | 适用引擎 | 停机代价 | 一致性级别 |
|---|---|---|---|
| 停写 + 冷拷贝 | 任意引擎 | 分钟到小时 | 应用一致 |
| 全局读锁 FTWRL | MyISAM 等非事务引擎 | 锁持有期间写入阻塞 | 崩溃一致（配合刷盘更佳） |
| 事务一致性快照 | InnoDB / PostgreSQL | 接近零 | 应用一致（单事务视角） |
| fsfreeze + 存储快照 | 多卷文件数据 | 秒级冻结 | 崩溃一致，卷间时间点对齐 |
事务引擎优先用自身机制：InnoDB 可用 mysqldump --single-transaction、MySQL 8.0 物理备份可用 LOCK INSTANCE FOR BACKUP，PostgreSQL 用 pg_start_backup / pg_basebackup 的备份模式；fsfreeze 主要解决多卷跨盘的时间点对齐。
锁与冻结都属于会影响业务写入的操作：先在测试环境量出快照耗时，把窗口控制在业务可接受范围内，并准备好锁未释放时的人工处置路径。