rsync不能直接同步运行中的mysql数据目录，根本原因是innodb等存储引擎的多文件并发写入与rsync逐文件拷贝机制存在逻辑时间点不一致冲突，导致备份文件状态错配、启动校验失败。
直接同步运行中的 MySQL 数据目录（如 /var/lib/mysql）会导致数据损坏，根本原因不是 rsync 本身有问题，而是 MySQL 的文件写入机制与 rsync 的文件快照式拷贝存在不可调和的冲突。
rsync 同步时 MySQL 正在持续写入文件
MySQL（尤其是 InnoDB）在运行时会并发修改多个物理文件：ibdata1、ib_logfile*、各表的 .ibd 文件、以及系统表空间和 redo log。这些文件之间有严格的时序和一致性依赖。而 rsync 是按文件逐个读取、传输的——它无法保证所有相关文件在同一逻辑时间点被“冻结”。比如：它可能刚复制完 t1.ibd，此时 MySQL 又往 ib_logfile0 写入了新日志，接着 rsync 才去复制 ib_logfile0。结果就是备份出来的 .ibd 和 ib_logfile* 状态不匹配，InnoDB 启动时校验失败，报错 Tablespace is missing 或 Database page corruption。
- MyISAM 表同样危险：
.MYD（数据）和.MYI（索引）不同步拷贝，会导致REPAIR TABLE失败或修复后数据错乱 - 即使只同步单个库目录（如
/var/lib/mysql/mydb），只要该库下有正在写入的表，风险依然存在 -
rsync -a能保留权限和时间戳，但完全无法解决逻辑一致性问题
为什么加 --delete 或 --partial 也救不了
有人试图用 rsync --delete 做“覆盖式同步”，或用 --partial-dir 防断连重传，这些对一致性毫无帮助。它们只影响传输过程的健壮性，不干预 MySQL 文件的内部状态。更危险的是：--delete 可能在同步中途删掉目标端尚未传完的文件，导致目标目录出现“半截表”；而 --partial-dir 仅用于临时存放未完成的文件，一旦 rsync 中断再续传，仍会从不一致的中间状态继续，无法回退到任一可用快照。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
-
--partial和--partial-dir解决的是网络中断问题，不是数据库一致性问题 - 哪怕 rsync 一次跑完没报错，只要 MySQL 在整个过程中没停写，结果仍是不可用的
- 某些人用
rsync配合FLUSH TABLES WITH READ LOCK，但这个锁对 InnoDB 的 DML 不生效，且锁期间长事务会堆积，实际不可靠
真正安全的替代方案只有三种
想用 rsync 类工具迁移 MySQL 数据，必须先让数据进入一个外部可一致拷贝的状态。这不是配置优化能绕开的，是存储引擎设计决定的硬约束。
-
停机 +
systemctl stop mysql后 rsync：最简单可靠，适用于维护窗口明确的场景；注意确保 mysqld 完全退出（检查ps aux | grep mysql），再开始 rsync - Percona XtraBackup 或 mysqldump 导出后再 rsync：XtraBackup 支持热备（对 InnoDB 加 checkpoint 锁），导出的是逻辑一致的物理备份；mysqldump 生成 SQL，适合小库或跨版本迁移
-
LVM 快照 + rsync：在支持 LVM 的系统上，先
lvcreate --snapshot，再 mount 快照并 rsync；快照提供时间点一致性，但要求 MySQL 数据目录在独立 LV 上，且 snapshot 空间要充足
真正容易被忽略的点在于：很多人看到 rsync 进度条跑完了、文件大小对得上、甚至能 ls 出表名，就以为迁移成功。但 InnoDB 启动时的崩溃恢复（crash recovery）阶段才会暴露问题——这时已经晚了。务必在目标端用 mysqld --initialize-insecure（仅初始化）或直接启动服务前，先确认源端已彻底停写，并验证备份完整性（例如用 xtrabackup --apply-log 或导入 dump 后 mysqlcheck -c）。
