能迁，但必须用--prepare+--copy-back两步走且从库MySQL必须停机；不能跳过prepare，也不能运行中直接copy-back，因XtraBackup备份是原始快照而非可启动镜像，需prepare重放redo、回滚事务、清理脏页才能生成可用系统表空间。
直接说结论：能迁，但必须用 --prepare + --copy-back 两步走，且从库 MySQL 必须停机；不能跳过 prepare，也不能在运行中直接 copy-back。
为什么不能直接 rsync 数据文件过去？
MySQL 8.0 的 InnoDB 表空间（.ibd）不是裸文件，它依赖重做日志（Redo Log）和数据字典状态的一致性。直接拷贝未处理的备份目录，里面的数据页可能处于“中间状态”——比如事务已提交但尚未刷盘、或回滚段未清理。强行启动会触发崩溃恢复失败，报错类似 InnoDB: Database page corruption on disk 或 Cannot continue operation。
- 物理备份 ≠ 文件复制，XtraBackup 备份出来的是“原始快照”，不是“可启动镜像”
-
--backup只负责拷贝 + 记录日志位置，不校验也不合并 - 跨服务器迁移时，目标机器的 MySQL 版本、页大小（
innodb_page_size）、加密配置（innodb_encrypt_tables）必须与源库完全一致，否则--prepare阶段就会失败
--prepare 是迁移中最容易被跳过的致命步骤
这一步才是真正让备份“活过来”的关键：它重放 Redo Log、回滚未提交事务、清理脏页、生成可用的 ibdata1 和系统表空间。没它，--copy-back 就是往数据库里塞一堆废砖。
- 必须在目标服务器上执行，且目标机器需安装同版本
xtrabackup（如源是 8.0.34，目标也得是 8.0.34） - 命令示例：
xtrabackup --prepare --target-dir=/path/to/backup/ - 如果备份是增量链（比如全量 + 两次增量），必须按顺序 prepare：
--prepare先跑全量，再用--prepare --incremental-dir=inc1合并 inc1，最后再用--incremental-dir=inc2合并 inc2 - 执行完后检查输出末尾是否有
completed OK!，没有就别往下走
--copy-back 前必须停掉 MySQL，且清空目标 datadir
很多人卡在这一步：MySQL 进程还在跑，或者只删了部分文件（比如只 rm -rf /var/lib/mysql/* 却漏了 socket、pid 文件），结果 --copy-back 看似成功，启动时报 Can't start server: Bind on TCP/IP port 或 Table 'mysql.user' doesn't exist。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 正确操作顺序：
systemctl stop mysqld→rm -rf /var/lib/mysql/*→chown -R mysql:mysql /var/lib/mysql→ 再执行xtrabackup --copy-back --target-dir=/path/to/backup/ -
--copy-back不会自动修复权限，必须确保目标目录属主是mysql:mysql，否则启动失败 - 目标
datadir路径要和源库一致（或通过--datadir显式指定），否则ibdata1和日志路径对不上 - 若目标 MySQL 启用了
secure_file_priv或 AppArmor/SELinux，可能拦截文件写入，需临时关闭或放行路径
迁移后必须验证 binlog 位点和用户权限
备份时记录的 xtrabackup_binlog_info 是后续主从搭建或时间点恢复的唯一依据，但它不会自动生效。而且 MySQL 8.0 的密码认证插件（caching_sha2_password）和账号权限在 mysql 库里，全量恢复后这些都原样回来了——但如果你没提前创建 backup_user 或改过 root 密码策略，可能连不上。
- 确认恢复后
cat /path/to/backup/xtrabackup_binlog_info，记下mysql-bin.0000xx和位置，用于后续CHANGE MASTER TO - 登录后立即执行
SELECT user, host, plugin FROM mysql.user;，检查是否所有账号都存在，特别是远程访问账号的host是否匹配新 IP - 若从库要接主库，别忘了
SET SQL_LOG_BIN = 0;再导入用户权限，避免误写 binlog - 首次启动后观察 error log，重点看有没有
InnoDB: Starting crash recovery（正常），或反复报failed to open table（说明 prepare 不完整）
真正麻烦的从来不是备份命令怎么写，而是 prepare 是否彻底、copy-back 前环境是否干净、以及恢复后那些藏在 mysql 库里的隐性依赖——比如角色绑定、密码历史策略、甚至 audit_log 插件的状态。每一步跳过验证，后面花三小时排障都未必找得到根因。
