tb级mysql迁移不能用物理冷拷贝，因需数据库完全关闭且确保一致性，而tb级实例通常无停机窗口；即使停机，未执行flush tables with read lock或innodb_fast_shutdown=0易致文件损坏，启动时出现表空间缺失、崩溃恢复卡死、部分表报错1932等故障。
TB级MySQL迁移为什么不能用冷拷贝
物理冷拷贝（直接rsync或cp数据目录）在TB级场景下基本不可行——不是慢，而是大概率失败。InnoDB的数据文件（ibdata1、.ibd）和日志文件（ib_logfile*、redo）必须处于一致性状态才能恢复，而冷拷贝要求数据库完全关闭。但TB级实例停机窗口往往不存在；即使能停，关库前未FLUSH TABLES WITH READ LOCK或未等innodb_fast_shutdown=0完成，拷出来的文件极可能损坏，mysqld --initialize-insecure后启动直接报Tablespace is missing或Corrupted page。
常见错误现象包括：
- 目标库启动时卡在
InnoDB: Starting crash recovery...，数小时无响应 -
SHOW ENGINE INNODB STATUS显示大量pending flushes或log sequence number mismatch - 部分表可查，部分表
ERROR 1932 (HY000)提示表不存在于引擎中
xtrabackup全量热备的三个硬性前提
用xtrabackup做TB级迁移，不是装完就能跑，必须满足三个底层条件，缺一不可：
- 源库和目标库MySQL主版本号必须一致（如都是
8.0.33），5.7备份不能用于8.0，反之亦然 - 目标机器磁盘剩余空间 ≥ 源库
data_length + index_length× 1.3（--prepare阶段会解压并重建日志，临时膨胀明显） - 必须提前确认
secure_file_priv不影响xtrabackup读取my.cnf中的配置路径，否则innobackupex会静默跳过关键参数（如innodb_log_file_size）
漏掉任意一条，xtrabackup --copy-back后启动失败概率超80%，且错误日志里往往只报Cannot open table这种模糊信息。
实际执行时最关键的三步命令与参数
别照抄文档默认参数——TB级数据下，几个关键开关不显式指定，xtrabackup会退化成“伪热备”：
- 备份阶段加
--no-lock --parallel=8 --compress --compress-threads=4：避免FLUSH TABLES WITH READ LOCK锁全局，多线程压缩减少IO压力 - 传输阶段不用
scp，改用rsync --partial --progress --compress：断点续传防网络抖动中断，压缩降低千兆网卡瓶颈 - 恢复前必须
xtrabackup --prepare --apply-log-only（首次）+--prepare（最终），尤其有增量备份链时，漏--apply-log-only会导致LSN not found
示例片段：
xtrabackup --backup --target-dir=/backup/full_$(date +%F) \ --no-lock --parallel=8 --compress --compress-threads=4 \ --rsync
注意：--rsync是加速备份本身，不是传输；它不替代后续rsync到目标机的步骤。
为什么xtrabackup比冷拷贝快，又比逻辑工具稳
根本差异不在“快”，而在“可控的一致性”。xtrabackup在拷贝数据文件的同时，持续监听并追写redo log，最后用--prepare把未刷盘的变更“重放”进数据页——这相当于在不停机前提下，人工模拟了一次崩溃恢复过程。而冷拷贝没有这个能力，逻辑工具（如mydumper）则把一致性压在SQL事务上，TB级下INSERT批量提交的原子性无法覆盖所有并发写入场景。
容易被忽略的点：
-
xtrabackup备份期间，源库innodb_buffer_pool_pages_dirty会缓慢上升，这是正常现象；但若超过总页数30%，说明innodb_io_capacity设得太低，需调高 - 目标库恢复后首次启动，务必检查
innodb_force_recovery=0（默认），否则可能跳过关键校验导致静默数据损坏 -
ib_logfile*大小必须和源库严格一致，否则mysqld拒绝启动，不能靠删掉重建——那是冷拷贝思维
