可行但须满足三前提：数据库已停机、权限为mysql:mysql、版本相同或兼容（5.7→8.0不支持）；否则启动必报错。
直接用 rsync -avz --delete 同步整个 /var/lib/mysql 目录到新机器，是可行的，但必须满足三个硬性前提：数据库已完全停机、目标目录权限严格为 mysql:mysql、源与目标 MySQL 版本相同或兼容（尤其注意 5.7 → 8.0 不支持物理迁移）。否则启动必报错，最常见的是 Can't start server: Bind on TCP/IP port 或静默失败。
为什么不能直接 rsync 运行中的 MySQL 数据目录
MySQL 的 InnoDB 引擎依赖内存状态与磁盘文件强一致。即使只差一次 checkpoint，ib_logfile* 和 ibdata1 就可能处于中间态。运行中 rsync 会复制出不一致的文件快照，恢复后 mysqld 启动时卡在 Starting crash recovery，甚至直接拒绝启动。
- 必须先执行
FLUSH TABLES WITH READ LOCK（仅对 MyISAM 有效），但对 InnoDB 不够；真正可靠的做法是mysqladmin -uroot -p shutdown完全停服 -
rsync默认不校验原子性，传输中断就得重来；而cp -a是单次原子操作，更适合冷迁移场景 - 若源库启用了加密表空间（
innodb_encrypt_tables=ON），密钥未导出则目标机无法解密，同步后启动失败且无明确报错
rsync 同步时必须加的关键参数和权限处理
停机后，不要用 rsync -avz /var/lib/mysql/ user@newhost:/var/lib/mysql/ 这种裸路径写法——它会把源目录内容“铺平”到目标目录下，容易覆盖关键配置文件如 auto.cnf，导致 UUID 冲突，主从复制断裂。
- 正确做法是同步整个目录层级：
rsync -avz --delete /var/lib/mysql/ user@newhost:/var/lib/mysql/（注意末尾斜杠） - 目标机上必须执行：
chown -R mysql:mysql /var/lib/mysql，缺一不可；否则mysqld启动时因无法访问mysql.sock或ib_logfile0报Permission denied - 若目标机 SELinux 开启，还需
restorecon -Rv /var/lib/mysql，否则同样 Permission denied
目标机启动前必须检查的三项配置
物理迁移不是“拷完就跑”，MySQL 对环境敏感度极高，以下三点漏一项，服务就起不来。
-
datadir配置必须显式指向新路径，且路径末尾不能有斜杠；检查my.cnf中[mysqld]段是否含datadir = /var/lib/mysql - 确认目标机 MySQL 版本与源机一致（
mysqld --version），5.7 的ibdata1无法被 8.0 读取，反之亦然；Percona Server 和官方 MySQL 也视为不同版本 - 若源库使用了
innodb_file_per_table=OFF，所有表数据都在ibdata1里，迁移后不能删掉该文件，也不能用--initialize重建，否则全库丢失
最易被忽略的是 auto.cnf 文件里的 server-uuid ——如果目标机之前装过 MySQL，残留的 auto.cnf 会导致启动时报 Server has gone away 或复制中断；迁移前务必确认目标 /var/lib/mysql/auto.cnf 是空的或已删除。
