rsync 直接拷贝 MySQL 数据文件大概率失败，因运行时文件被 InnoDB 锁定且持续写入导致不一致；即使停库，版本、页大小、校验算法等配置不一致也会启动失败。
rsync 直接拷贝 MySQL 数据文件为什么大概率失败
因为 MySQL 的数据文件（如 ibdata1、ib_logfile0、表空间文件）在运行时被 InnoDB 持有锁且持续写入，直接 rsync 拷贝会导致文件不一致；即使停库拷贝，若新旧服务器的 MySQL 版本、页大小（innodb_page_size）、校验算法（innodb_checksum_algorithm）或文件格式（innodb_file_format）不一致，启动时会报 Tablespace is missing for table 或直接拒绝启动。
实操建议：
- 停库不是万能解法，必须核对
my.cnf中关键 InnoDB 配置项是否完全一致 - 若旧库启用了
innodb_file_per_table=OFF，所有表共享ibdata1，迁移后无法单独恢复某张表 -
rsync -avz --delete仅适合冷备份场景，且必须确保目标目录权限为mysql:mysql，否则启动失败报Can't start server: Bind on TCP/IP port或更隐蔽的Permission denied错误
mysqldump + 重放是最稳妥的跨版本迁移方式
它绕过文件层差异，只依赖 SQL 语义，兼容性最好。但要注意导出参数直接影响恢复成败和性能。
实操建议：
- 务必加
--single-transaction（InnoDB 表）或--lock-all-tables（含 MyISAM），否则导出会漏数据或卡死 - 用
--routines --triggers --events导出存储过程、触发器、事件，缺一不可 - 避免用
--all-databases直接导出，应分库导出并显式指定--databases db1 db2，防止mysql系统库被覆盖导致权限丢失 - 导入前清空目标库：先
DROP DATABASE IF EXISTS db1，再CREATE DATABASE db1 CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci（注意字符集匹配源库）
Percona XtraBackup 能热备但配置门槛高
它是唯一支持真正热备份的开源方案，但要求严格匹配 MySQL/Percona Server 版本，且恢复流程比 mysqldump 多三步：prepare → copy-back → chown → 启动。
常见错误现象：
-
xtrabackup: Error: xtrabackup_read_only_file must be specified：未加--target-dir或路径不存在 - prepare 后
ib_logfile*仍存在，直接 copy-back 会报log file is not empty - 恢复后
mysqld启动卡在Starting crash recovery...：说明 prepare 不完整，需补加--apply-log-only对增量备份处理
使用场景：生产环境不能停机 > 10 分钟，且 DBA 熟悉其生命周期管理。
同步工具选型：pt-table-sync vs. MySQL 主从复制
如果只是“追平”两个已存在的库（比如灰度切换前校验），pt-table-sync 更轻量；如果要长期保持双写一致性，必须走主从（replication），但注意 GTID 和 binlog 格式必须一致。
实操要点：
-
pt-table-sync --sync-to-master h=old_ip,u=root,p=xxx会自动检测并修复行级差异，但默认不执行，加--execute才生效 - 主从搭建前，必须确认
server-id唯一、log-bin开启、binlog_format=ROW（避免函数/临时表同步失败） - 从库报
Slave_SQL_Running: No且Last_SQL_Error是Duplicate entry：大概率是手动改了从库数据，需跳过或重做从库
复杂点在于：没有银弹。冷迁移看一致性，热迁移看工具链成熟度，而任何方案都绕不开权限、字符集、时区、SQL mode 这五个隐性依赖项——它们不报错，但会让数据“看起来对，实际错”。
