不能直接用mysqldump --single-transaction做大规模集群快照，因为它仅保证单实例InnoDB事务一致性，无法控制主从延迟、GTID偏移、binlog rotate时机及分片间逻辑时序，导致多节点备份时间点不一致，恢复后出现主键冲突、外键断裂、事务状态错乱；必须通过LVM+FLUSH TABLES WITH READ LOCK全局协调实现严格对齐的物理快照。
为什么不能直接用 mysqldump --single-transaction 做大规模集群快照？
它在单实例上能保证InnoDB一致性，但在集群（尤其主从+分库分表）中会立刻失效：主库执行START TRANSACTION WITH CONSISTENT SNAPSHOT时，从库的复制延迟、GTID位点偏移、binlog rotate时机都不受控。结果是备份出来的多个库/实例时间点不一致，恢复后主键冲突、外键断裂、事务状态错乱。
常见错误现象：mysqldump导出完成时，从库Seconds_Behind_Master还在跳变；恢复后发现订单表有重复ID，但支付表没对应记录。
- 必须停写或全局协调，否则无法对齐所有节点的“同一时刻”
-
--master-data=2只记录主库当前binlog位置，不保证从库同步到该点 - 跨分片备份时，
mysqldump无法感知shard间逻辑时序，备份顺序即恢复顺序，极易破坏业务一致性
真正可行的一致性快照：LVM + FLUSH TABLES WITH READ LOCK 组合
这不是“纯热备”，但对TB级集群来说，它是唯一能严格对齐物理状态与逻辑位点的方法。核心在于：先锁住所有写入，再瞬间打LVM快照，最后立刻解锁——整个过程控制在秒级，业务影响可控。
使用场景：每日凌晨低峰期全量备份、灾备基线构建、重大版本升级前固化状态。
- 要求MySQL数据目录、binlog目录、relay log目录全部位于同一LVM卷组（如
/dev/vg_mysql/lv_data和/dev/vg_mysql/lv_binlog） - 执行前必须确认所有从库已追平主库：
SELECT MASTER_POS_WAIT('mysql-bin.000166', 123456789)返回非NULL - 锁阶段命令顺序不能颠倒：
FLUSH TABLES WITH READ LOCK→SHOW MASTER STATUS→lvcreate -s -n snap_$(date +%Y%m%d_%H%M) /dev/vg_mysql/lv_data→UNLOCK TABLES - 快照大小至少预留原卷25%，否则COW写入会触发
snapshot is full错误导致快照失效
xtrabackup --lock-ddl-per-table 在集群中仍需配合LVM
XtraBackup本身不解决跨实例一致性，它的--lock-ddl-per-table只防止DDL变更，不影响DML并发。在集群里单独跑xtrabackup，各节点备份时间差可能达数分钟，binlog位点根本无法对齐。
正确做法是把它嵌入LVM快照流程：在FLUSH TABLES WITH READ LOCK之后、UNLOCK TABLES之前，用xtrabackup --no-lock --backup把快照卷内容拷出——此时快照已是静止状态，XtraBackup只需做文件拷贝，无需再加锁。
- 避免直接在生产卷上跑
xtrabackup --backup：IO压力叠加COW会拖慢主库响应 -
--prepare阶段必须在备份机执行，不能在快照挂载点上直接--apply-log，否则破坏快照元数据 - 恢复时，先用
lvconvert --merge回滚快照（需关机），再用XtraBackup的--copy-back还原，比纯LVM恢复更可靠
最容易被忽略的细节：binlog位点与快照的绑定校验
快照本身不含binlog，但恢复后必须能继续复制。很多人只记了SHOW MASTER STATUS输出，却没验证该位点是否真实存在于快照内的binlog文件中。
实操建议：在UNLOCK TABLES后立即执行mysqlbinlog --base64-output=decode-rows -v /path/to/snap_mount/mysql-bin.000166 | grep -A5 "position 123456789"，确认该事件确实存在且未被rotate掉。若缺失，说明快照生成时binlog已滚动，必须重新打快照。
这个步骤漏掉，恢复后的从库会报Could not find first log file name in binary log index file或log position not found，只能重做全量同步。
