xtrabackup跨机房迁移必须严格遵循五参数备份（--backup、--no-lock、--slave-info、--parallel=4、--defaults-file）、两步prepare（先--apply-log-only再最终prepare）、停库清空datadir及SELinux上下文校验，缺一将导致InnoDB崩溃或启动失败。
xtrabackup 是唯一能在 4 小时内完成 TB 级 MySQL 物理迁移的工具，但“快速”不等于“跳步骤”。漏掉任一关键环节，恢复时卡在 InnoDB: Database page corruption 或启动失败，比 mysqldump 还慢。
备份命令必须带这 5 个参数，少一个就可能无法恢复
xtrabackup 不是 cp 的替代品，它生成的是“崩溃恢复前状态”的文件集。生产环境必须显式指定：
- --backup：必须写，否则默认当 prepare 或 copy-back 操作
- --no-lock：跳过 FLUSH TABLES WITH READ LOCK，避免跨机房网络延迟引发应用超时
- --slave-info：生成 xtrabackup_slave_info，记录 MASTER_LOG_FILE 和 MASTER_LOG_POS，后续搭从库可直接 CHANGE MASTER TO MASTER_AUTO_POSITION=1- --parallel=4：设为 CPU 核数的 75%，过高反而因 IO 竞争变慢；实测 8.2TB 数据用 8 线程比 16 线程快 22%
- --defaults-file=/etc/my.cnf：强制读取真实配置，否则可能误判 datadir 或 innodb_page_size，导致 ibdata1 路径错位
别加 --safe-slave-backup：它会停 SQL 线程，造成主从延迟突增，且仍需锁表，违背低影响初衷。
prepare 必须分两步，否则增量数据全丢
备份传到目标机后，不能直接 --copy-back。InnoDB 需先重放 redo log，再回滚未提交事务——这两步必须拆开：
- 全量备份执行：xtrabackup --prepare --apply-log-only --target-dir=/backup/full- 每个增量备份按时间顺序执行：xtrabackup --prepare --apply-log-only --target-dir=/backup/full --incremental-dir=/backup/inc_20260701- 最后一次执行（不带 --apply-log-only）：xtrabackup --prepare --target-dir=/backup/full
漏掉中间的 --apply-log-only，增量日志会被错误回滚；漏掉最后一步不带该参数，数据文件仍处于“未回滚事务”状态，MySQL 启动时直接 abort。
copy-back 前必须停库 + 清空 datadir，chown 不够
xtrabackup --copy-back 不是复制到任意目录，而是还原到 MySQL 实际 datadir。操作前：
- 执行 systemctl stop mysqld，并确认 ps aux | grep mysqld 无残留进程、netstat -tlnp | grep :3306 端口已释放
- 彻底清空：rm -rf /var/lib/mysql/*（不是只删 .ibd，ibdata1、ib_logfile*、mysql/ 子目录都得清）
- chown -R mysql:mysql /var/lib/mysql 后，还需检查 SELinux 上下文：chcon -R -t mysqld_db_t /var/lib/mysql（CentOS 7），Ubuntu 则需确认 AppArmor profile 未拦截
- 若目标机 my.cnf 中 innodb_log_group_home_dir 指向非默认路径，copy-back 后需手动同步 ib_logfile* 到该目录，否则启动报 Cannot open or create file
最容易被忽略的三个兼容性断点
物理迁移绕过 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 模式，卡在启动阶段
- GTID 状态未对齐：源库没开 gtid_mode=ON 或 enforce_gtid_consistency=ON，START SLAVE 后立即报 Got fatal error 1236，无法定位同步起点
真正决定能不能“快速”的，从来不是备份速度，而是 prepare 是否提前验证过、datadir 是否彻底清空、以及 GTID 和字符集这些底层参数是否对齐。这些地方错一个，4 小时窗口就废了。
