XtraBackup是唯一能在4小时内完成TB级MySQL物理迁移的工具，因其绕过SQL层直接复制InnoDB页、支持并行压缩与流式传输，且实测8.2TB数据全量+增量+apply log总耗时3小时42分；但必须满足GTID开启、版本参数严格一致、prepare在目标机执行等关键约束。
物理迁移是TB级MySQL数据在4小时内完成切换的可行路径，但必须放弃“直接拷贝文件”这种想当然的做法——innodb_file_per_table=ON、lower_case_table_names不一致、ibdata1共享表空间残留、GTID状态未对齐，任何一个都可能让恢复卡在crash recovery阶段，拖垮整个时间窗口。
为什么xtrabackup是唯一能压进4小时的物理工具
mysqldump是逻辑导出，单线程+SQL解析+字符集转换，8TB数据光导出就超10小时；而xtrabackup走的是InnoDB底层页复制，跳过SQL层，支持并行压缩（--parallel=8 --compress）、流式传输（--stream=xbstream）和增量备份。实测中，某8.2TB MySQL 5.7集群在万兆网络+NVMe目标盘环境下，全量+最后一次增量+apply log总耗时3小时42分。
关键约束条件：
- 源库必须开启
gtid_mode=ON且enforce_gtid_consistency=ON，否则无法精准定位同步起点 - 目标库需预置相同版本的MySQL二进制包，且
innodb_page_size、collation_server等核心参数必须与源库严格一致 -
xtrabackup版本不能高于源MySQL版本（例如MySQL 5.7.32只能用percona-xtrabackup-24，不能用8.0版）
真正决定能否4小时切走的三个临界操作点
不是备份快慢，而是这三个环节是否可控：
- 备份后
--prepare阶段必须在目标机执行，而非源机——避免源机I/O打满导致业务抖动；同时要加--use-memory=16G加速redo应用，否则8TB数据apply log可能耗时90分钟以上 - 恢复时禁用
innodb_doublewrite=OFF（仅限一次性切换场景），可缩短20%恢复时间，但必须确保目标盘是企业级SSD，避免断电丢页 - 主从同步启动前，先在目标库执行
SET GLOBAL read_only=ON，再CHANGE MASTER TO ... MASTER_AUTO_POSITION=1，最后START SLAVE——跳过Seconds_Behind_Master反复归零又跳变的过程，避免误判同步完成
切换瞬间最容易被忽略的兼容性断点
物理迁移绕过了SQL语法校验，但以下问题会在START SLAVE后立刻暴露：
- 源库用了
MyISAM引擎的系统表（如mysql.proc），目标MySQL 8.0已移除该引擎，会报错Table 'mysql.proc' doesn't exist；必须提前用mysqldump -t -n -d mysql proc单独导出重建 - 源库
character_set_server=utf8，但实际表用的是utf8mb4，物理备份会照搬ibd文件，但目标库启动时因默认字符集不匹配触发innodb_force_recovery模式，卡在启动阶段 - Linux源库
lower_case_table_names=0，而目标机为Windows或配置了lower_case_table_names=1，会导致SHOW TABLES为空，但SELECT * FROM `user`仍可查——这种“半隐身”状态极难排查
4小时是物理迁移的硬极限，不是平均值。它要求你提前两周完成网络带宽压测、目标盘IOPS验证、GTID一致性快照比对，并把STOP SLAVE; RESET SLAVE ALL;这类回退指令写进切换checklist第一行——因为一旦Seconds_Behind_Master开始缓慢爬升，而不是稳定归零，说明binlog事件已在内部损坏，此时继续等待只会浪费停机窗口。
