xtrabackup --prepare 后启动 MySQL 报“Tablespace is missing”错误，因增量备份必须严格按序合并，且除最后一次外均需加 --apply-log-only，否则 redo log 与数据页状态不一致导致校验失败。
为什么 xtrabackup --prepare 后启动 MySQL 会报错 Tablespace is missing
因为增量备份的 --prepare 必须严格按顺序合并，且最后一次必须加 --apply-log-only（除最终那次）。漏掉或顺序错，InnoDB 的 redo log 和 page 状态就对不上，启动时引擎发现数据页校验失败，直接拒载表空间。
- 全量备份后第一次
--prepare必须带--apply-log-only - 每个增量备份都必须用上一次 prepare 过的目录作为
--target-dir，且自身也加--apply-log-only - 最后一个增量（或仅全量）的
--prepare才不加--apply-log-only，否则数据没真正“回滚完成” - 检查
xtrabackup_binlog_info和xtrabackup_slave_info是否随每次 prepare 更新——没更新说明 prepare 没生效
从 backup_dir 恢复到新实例前，MySQL 配置哪些项不能照抄原库
直接 cp 原 my.cnf 到新从库，大概率启动失败或同步异常。关键冲突点在数据路径、日志路径和复制元数据位置。
-
datadir必须指向你cp -r后的真实恢复路径，比如/var/lib/mysql_recover，不是原库的/var/lib/mysql -
innodb_log_group_home_dir和innodb_log_files_in_group若与备份时不一致，mysqld会拒绝启动；建议删掉旧ib_logfile*再启动（前提是--prepare已做完） -
server_id必须改，否则主库收不到 ACK，GTID 或 binlog pos 同步全乱 -
relay_log和relay_log_index路径建议显式指定，避免和原库共用文件名导致覆盖
执行 CHANGE MASTER TO 时，MASTER_LOG_FILE 和 MASTER_LOG_POS 从哪取
别翻主库 SHOW MASTER STATUS——那是当前最新位点，从库恢复完的数据只到备份那一刻，强行连最新位点会丢数据或报 Could not find first log file name in binary log index file。
- 全量备份里找
xtrabackup_binlog_info，它记录的是「备份结束瞬间」主库的File和Position - 有增量备份的话，最后一个增量包里的
xtrabackup_binlog_info才是最终位点（注意：不是xtrabackup_slave_info，那个是备份时刻的从库状态，不适用） - 如果启用了 GTID，优先用
SET GLOBAL gtid_purged = '...'+CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1，更安全 - 确认主库该 binlog 文件确实存在且未被
PURGE，否则START SLAVE直接报错
START SLAVE 后 Seconds_Behind_Master 一直为 NULL 怎么查
这不是延迟，是同步根本没跑起来。常见于 IO 线程卡住，而 SQL 线程压根没启动。
- 先看
SHOW SLAVE STATUS\G中Slave_IO_Running和Slave_SQL_Running是否都为Yes；只要一个为No，Seconds_Behind_Master就是NULL - 如果
IO_Running = No，重点查Last_IO_Error：常见是主库账号没REPLICATION SLAVE权限，或网络不通，或MASTER_HOST解析失败 - 如果
SQL_Running = No，看Last_SQL_Error：多数因 GTID 冲突、表结构不一致、或sql_slave_skip_counter被误设过 - 别忽略
Retrieved_Gtid_Set和Executed_Gtid_Set是否在增长——不增长说明 IO 或 SQL 线程实际卡死，不是延迟问题
恢复从库最耗时间的环节从来不是拷贝数据，而是 prepare 顺序错一次就得重来，以及位点配错后重拉全量。盯紧每个 xtrabackup_binlog_info 的内容，比反复试启动更省事。
