LVM快照本身不备份数据，仅生成逻辑卷时间点视图；安全升级需快照+数据库静默+挂载验证三者协同，且MySQL数据目录必须运行在LVM逻辑卷上，否则快照无效。

LVM快照本身不“备份数据”，它只在秒级内生成一个逻辑卷的时间点视图，为数据库升级前提供一致性数据基线。真正实现安全、可回滚的升级保障，靠的是快照 + 数据库静默 + 可挂载验证三者协同，不是单靠lvcreate一条命令。

必须确认 MySQL 数据目录运行在 LVM 逻辑卷上
这是硬性前提，跳过等于白做：

• 运行 df -hT /var/lib/mysql，输出设备应类似 /dev/mapper/vg0-mysql_lv 或 /dev/vg0/mysql_lv
• 若显示 /dev/sda2 或 /dev/nvme0n1p1，说明没走 LVM，快照命令会直接报错，需先迁移数据到 LV（停机操作，无法秒级）
• 同时检查 vgdisplay vg0 | grep "Free PE"，确保有足够空闲空间（例如预估升级窗口写入量 × 1.5，最低 2GB）

升级前执行数据库一致性冻结（关键步骤）
MySQL 在运行中直接打快照，InnoDB 页可能处于半写状态，恢复后大概率报 Database page corruption：

• 在同一 MySQL 会话中顺序执行：

  FLUSH TABLES WITH READ LOCK;
  FLUSH LOGS;                -- 滚动当前 binlog，确保日志落盘
  FLUSH ENGINE LOGS;         -- 强制 InnoDB 刷脏页和 redo 日志
  SHOW MASTER STATUS;        -- 记录 File 和 Position（后续回滚或 PITR 用）

• 立即执行快照命令（在 SHOW MASTER STATUS 后、UNLOCK TABLES 前）：

  lvcreate -L 2G -s -n mysql_preupgrade_$(date +%Y%m%d_%H%M) /dev/vg0/mysql_lv

• 执行完立刻 UNLOCK TABLES;，整个锁持有时间应 ≤ 3 秒；超时说明有长事务，需 KILL 掉阻塞进程

挂载快照并验证可用性（不能跳过）
快照创建成功 ≠ 能直接读取，尤其 XFS/ext4 处理方式不同：

• 先检查状态：lvs -o +attr /dev/vg0/mysql_preupgrade_*，确认 Attr 第 5 位是 s（snapshot），不是 S（suspended）
• 若为 S，运行 lvchange -ay /dev/vg0/mysql_preupgrade_* 激活
• 创建挂载点并只读挂载：

  mkdir -p /mnt/preup_snap
  mount -o ro,nouuid /dev/vg0/mysql_preupgrade_* /mnt/preup_snap

• 验证核心文件存在且可读：

  ls -l /mnt/preup_snap/ibdata1 /mnt/preup_snap/mysql/user.frm 2>/dev/null && echo "✅ 快照挂载有效"

• 验证后立即 umount /mnt/preup_snap

升级完成后保留快照，直到新版本稳定运行 24 小时以上

• 不要升级一完成就删快照。若发现兼容问题、性能异常或数据错乱，可快速回退：
  • 停 MySQL：systemctl stop mysqld
  • 卸载原数据卷：umount /var/lib/mysql
  • 清空原 LV 并拷贝快照内容（注意权限）：

    dd if=/dev/zero of=/dev/vg0/mysql_lv bs=1M count=100  # 清零头段
    rsync -aHAX /mnt/preup_snap/ /var/lib/mysql/
    chown -R mysql:mysql /var/lib/mysql

• 确认无误后再执行 lvremove /dev/vg0/mysql_preupgrade_* 释放空间

整个流程中，“秒级”体现在快照元数据创建和锁表时间，而非备份动作本身。真正的安全性来自每一步的验证闭环，而不是速度。