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早已被删,增量恢复彻底失效。











