必须先执行FLUSH TABLES WITH READ LOCK，因为它强制InnoDB刷脏页、写redo日志并阻塞写入，使LVM快照捕获崩溃一致状态；跳过此步直接快照将导致恢复时报InnoDB: Database page corruption。
不能直接对运行中的 MySQL 打 LVM 快照 —— 除非你已经让 InnoDB 处于崩溃一致状态，否则恢复时大概率报 InnoDB: Database page corruption。
为什么 FLUSH TABLES WITH READ LOCK 是必须的
MySQL 的 InnoDB 引擎靠 redo log 和 buffer pool 异步刷盘，文件系统快照捕获的是磁盘块瞬间状态，不感知事务提交进度。FLUSH TABLES WITH READ LOCK 不只是“锁表”，它会强制：
• 同步所有脏页到 .ibd 和 ibdata1
• 刷写所有未落盘的 redo 日志（ib_logfile*）
• 阻止新事务写入，让整个数据目录静默
这一步完成后，LVM 快照才真正对应一个可恢复的、InnoDB 崩溃一致性快照点。
常见错误现象：跳过这步直接 lvcreate，恢复后 mysqld 卡在 Starting crash recovery 或启动失败。
快照创建必须在 SHOW MASTER STATUS 之后、UNLOCK TABLES 之前
锁住数据库后，必须立刻获取 binlog 位点，再打快照，最后解锁 —— 三步顺序不能乱，窗口控制在 2 秒内：
• mysql -e "FLUSH TABLES WITH READ LOCK"
• mysql -e "SHOW MASTER STATUS\G" > /tmp/master_pos.txt（记录 File 和 Position）
• lvcreate -L 5G -s -n mysql_snap_$(date +%Y%m%d_%H%M) /dev/vg0/mysql_lv
• mysql -e "UNLOCK TABLES"
注意：UNLOCK TABLES 必须在快照创建成功后立即执行；如果 lvcreate 因空间不足失败（报 snapshot is full），锁仍被持有，业务写入会持续阻塞。
挂载快照后必须只读 + 强制 tar 导出，不能直接拷 LV 设备
LVM 快照本身只是 COW 元数据引用，/dev/vg0/mysql_snap 不是完整数据文件集合，不能直接 cp 或 rsync 设备节点。正确做法：
• 创建只读挂载点：mkdir -p /mnt/snap_mysql
• 挂载前处理 xfs（若用 xfs）：xfs_repair -o force_geometry /dev/vg0/mysql_snap
• 只读挂载：mount -o ro,nouuid /dev/vg0/mysql_snap /mnt/snap_mysql
• tar 打包（保留权限和扩展属性）：tar --acls --xattrs -czf /backup/mysql_$(date +%F_%H%M).tar.gz -C /mnt/snap_mysql .
容易踩的坑：
• 忘记 -C 参数导致打包绝对路径，还原时覆盖系统目录
• 挂载时不加 ro，后续误操作修改快照内容破坏一致性
• xfs 文件系统跳过 xfs_repair -o force_geometry，挂载时报 wrong fs type
快照空间不是“备份大小”，而是 COW 缓冲区容量
-L 5G 指的是快照卷能容纳多少“原卷被修改的块”，不是最终备份包大小。它取决于锁表期间原卷的写入量（如 audit 日志、socket 文件、临时表等）。经验公式：
• 最低预留：原 LV 容量的 3%～5%，且不小于 1G
• 更稳妥：按停机窗口内预估写入量 × 1.5（例如每秒写入 20MB，锁表 2 秒 → 至少配 60MB）
一旦超出，lvs 显示 active (invalid)，快照失效，mount 会失败。
检查命令：lvs -o +attr,origin，确认 Attr 第 5 位是 s（snapshot），不是 S（suspended）；若为 S，需先 lvchange -ay /dev/vg0/mysql_snap 激活。
