直接用冷备重建从库必须先执行xtrabackup --prepare再同步文件，否则mysql启动报错；需加--slave-info（或8.0.23+的--source-data=2）获取复制位点；gtid模式下须手动设置gtid_purged；--prepare需充足磁盘空间；binlog_format必须为row；server_id不能与主库重复。
直接用冷备数据重建从库同步关系，关键不是“拷过去就完事”，而是必须在 xtrabackup --prepare 完成后再同步文件，否则 MySQL 启动必报 Tablespace is missing 或 InnoDB: Operating system error number 2。
备份时漏掉 --slave-info 就等于白做
没加这个参数，备份目录里就不会生成 xtrabackup_slave_info，你恢复后根本不知道该从哪个 binlog 文件和位置开始复制。MySQL 8.0.23+ 推荐改用 --source-data=2，效果一样，但语义更明确。
-
--slave-info必须和--backup一起用，单独加没用 - 如果主库开了 GTID，还得额外确认
xtrabackup_binlog_info里的Executed_Gtid_Set值，恢复后要手动执行SET GLOBAL gtid_purged = '...'; - 别信“备份时加了
--no-lock就能不锁表”——DDL 正在跑时它照样卡住，老实用--lock-ddl-per-table
恢复顺序错一步，InnoDB 就拒绝启动
很多人把原始备份目录直接 rsync 到从库 datadir，结果 MySQL 启不起来。xtrabackup 备份不是快照，是需要回滚+重放的中间态。
- 先在备份机（或空闲机器）上跑：
xtrabackup --prepare --target-dir=/backup/full_2024-06-15 - 再清空从库
datadir（保留mysql系统库目录结构，别删空整个目录） - 最后用
rsync -avP --delete同步的是 prepare 后的目录，不是原始备份目录
磁盘空间不够，--prepare 阶段就会失败
--prepare 过程中会解压、回滚未提交事务、应用 redo log，临时占用空间常达原数据量的 1.5 倍。主库 datadir 实际占 200G，从库剩余空间低于 300G 就可能卡在 prepare 中途。
- 查真实占用：
du -sh /var/lib/mysql/* | grep -vE '(mysql|performance_schema|sys)'，别只看df -h - 主库
binlog_format必须是ROW，MIXED或STATEMENT会导致 apply-log 后位点不可靠 - 主库
server_id和待重建从库不能相同，否则CHANGE REPLICATION SOURCE会静默失败，状态卡在Connecting
最常被跳过的动作是恢复后手动设置 gtid_purged——只要主库开了 GTID，这步就是硬性前提，缺了它 START REPLICA 会直接拒绝执行，错误也不明显，得盯 SHOW REPLICA STATUS\G 里 Retrieved_Gtid_Set 是否为空。
