LVM快照不能直接用于TB级MySQL跨机迁移，仅能秒级冻结状态；真迁移需配合停机或XtraBackup协调，且MySQL数据目录必须位于LVM逻辑卷上，否则lvcreate --snapshot报错；创建快照前须在同会话中依次执行FLUSH TABLES WITH READ LOCK、FLUSH LOGS、FLUSH ENGINE LOGS、SHOW MASTER STATUS，再立即建快照并UNLOCK TABLES；ext4挂载需加-o nouuid,ro，xfs需先xfs_repair -n再挂载；迁移本质是拷贝+校验+binlog重放，快照空间与binlog保留周期须匹配。
不能直接用LVM快照“迁移”TB级MySQL——快照只冻结状态，不负责传输；真要跨机迁移，必须配合停机窗口或XtraBackup协调，否则大概率恢复失败。
确认MySQL数据目录是否在LVM逻辑卷上
这是硬性前提，lvcreate --snapshot 命令遇到非LVM设备会直接报错 device-mapper: reload ioctl failed: Invalid argument。别跳过这步。
- 运行
lsblk，找到/var/lib/mysql挂载点对应的设备名（比如sda3），看 TYPE 列是否为lvm - 执行
df -hT /var/lib/mysql，检查 Filesystem 是否以/dev/mapper/或/dev/vg0/lv_mysql开头 - 若显示
/dev/sda2或/dev/nvme0n1p1，说明不在LVM上——此时迁移=先停MySQL、rsync全量数据、重建LV、改datadir、修复权限，耗时远超“秒级”
创建快照前必须完成InnoDB一致性操作
仅执行 FLUSH TABLES WITH READ LOCK 不足以保证InnoDB一致性。锁表后若直接打快照，恢复时极大概率触发 InnoDB: Database page corruption。
- 所有命令必须在同一个MySQL会话中顺序执行：
FLUSH TABLES WITH READ LOCK;-
FLUSH LOGS;（滚动当前binlog，确保后续可截断） -
FLUSH ENGINE LOGS;（强制刷redo日志到磁盘） -
SHOW MASTER STATUS;（记录File和Position，后面增量恢复要用） - 立刻执行
lvcreate -L 10G -s -n mysql_snap_$(date +%s) /dev/vg0/lv_mysql - 紧接
UNLOCK TABLES;，整个锁持有时间应 ≤3 秒；超时说明有长事务，查SHOW PROCESSLIST并KILL
挂载快照卷时ext4和xfs行为差异极大
快照创建成功 ≠ 能直接挂载。文件系统类型决定你下一步该加什么选项，错一个就报 wrong fs type 或 bad superblock。
- 对于
ext4：默认拒绝挂载同UUID的快照卷，必须加-o nouuid，例如mount -o nouuid,ro /dev/vg0/mysql_snap_1727542440 /mnt/snap - 对于
xfs：不能直接挂载只读快照，需先运行xfs_repair -n /dev/vg0/mysql_snap_1727542440（-n 表示只检测），再用-o ro,nouuid挂载 - 挂载后务必验证：进入
/mnt/snap能看到ibdata1、ib_logfile0、数据库子目录，且ls -l显示属主为mysql:mysql
跨机迁移不是快照的事，是拷贝+校验+重放的事
LVM快照本身不跨网络。TB级数据迁移的核心瓶颈从来不是快照创建速度，而是物理拷贝带宽、目标机IO能力、以及恢复后binlog重放的完整性。
- 拷贝建议用
rsync -av --sparse --compress /mnt/snap/ user@target:/var/lib/mysql/，--sparse对稀疏文件（如未初始化的ibdata1）省空间，--compress减少网络传输量 - 目标机必须提前停MySQL、清空
/var/lib/mysql、chown mysql:mysql、关闭selinux或设对上下文 - 恢复后启动MySQL前，必须用备份时记录的
File/Position手动指定CHANGE MASTER TO ... MASTER_LOG_FILE='...', MASTER_LOG_POS=...，再START SLAVE补齐快照之后的变更 - 快照空间大小要预留足够：TB级库在迁移窗口内写入量可能达几十GB，
lvs -o +data_percent实时监控快照占用，超80%立即告警
真正容易被忽略的是：快照卷的生命周期必须短于MySQL binlog保留周期。如果快照挂了两天才拷完，而 expire_logs_days=1，那 Position 对应的binlog早已被删，增量恢复彻底失效。
