MySQL Clone 插件不支持直接远程克隆；仅支持本地克隆或通过组复制实现的受限“伪远程”克隆，通用远程克隆需结合外部工具传输快照目录，并严格满足版本、权限、配置等一致性要求。
MySQL Clone 插件是否支持直接远程克隆？
不支持。MySQL 官方 CLONE 插件（8.0.17+）只允许本地克隆（CLONE LOCAL DATA DIRECTORY）或通过 XCom（组复制底层通信）实现的“伪远程”克隆，但该方式要求 donor 和 recipient 在同一个 MySQL Group Replication 集群中，且必须启用 group_replication_clone_threshold 等配套配置——它不是通用意义上的跨网络、跨机器克隆。
所谓“远程传输”，实际是两步：先在 donor 上用 CLONE LOCAL 生成一份物理快照目录；再用外部工具（如 rsync、tar + ssh、scp）把快照目录传到目标机；最后在 recipient 上用 CLONE INSTANCE FROM（需提前配置好 donor 的可访问地址和端口）触发接收与应用。
- donor 必须开启
clone_valid_donor_list，显式加入 recipient 的 IP 或主机名 - recipient 的
datadir必须为空，且不能运行 mysqld 实例 - 双方 MySQL 版本需完全一致（包括小版本号），否则
CLONE命令会报错ER_CLONE_DONOR_VERSION_MISMATCH
如何安全导出 Clone 快照并压缩传输？
Clone 插件生成的快照是完整、一致、可立即启动的物理副本，但默认不压缩、不加密，直接 rsync 整个目录易受网络中断影响，也浪费带宽。推荐做法是：在 donor 上完成克隆后，立刻打包为流式压缩包并通过管道直传 recipient。
例如，在 donor 上执行：
mysql -e "CLONE LOCAL DATA DIRECTORY '/tmp/clone_snapshot';" cd /tmp/clone_snapshot tar -cf - . | pigz -c | ssh user@recipient-host "cd /var/lib/mysql && tar -xf -"
-
pigz比gzip多线程压缩更快，适合大库；若无 pigz，可用gzip -c - 务必确认 recipient 的
/var/lib/mysql目录权限为mysql:mysql，否则启动失败 - 不要在打包前删除 donor 的快照目录——它会被
CLONE INSTANCE FROM自动清理，但手动删了会导致 recipient 接收失败并报ER_CLONE_DONOR_NOT_FOUND
recipient 启动失败常见原因与修复
即使传输完成，mysqld --initialize-insecure 不再适用，必须用 CLONE INSTANCE FROM 让 MySQL 自动校验并接管数据。常见失败点集中在权限、路径和配置一致性上：
- recipient 的
my.cnf中datadir必须指向你传入的目录（如/var/lib/mysql），且该路径下不能有ibdata1、ib_logfile*等残留文件 - 如果 donor 使用了加密表空间（
innodb_encrypt_tables=ON），recipient 必须启用相同密钥环插件（keyring_file或keyring_encrypted_file），否则报ER_CLONE_ENCRYPTION_MISMATCH - recipient 启动时若卡在
Starting clone recovery，大概率是 donor 的 binlog 文件（mysql-bin.*）被一并传入了快照目录——Clone 快照默认不含 binlog，如有，需手动清空 recipient 的mysql-bin.*和mysql-bin.index
为什么不能跳过 donor 直接用 rsync 同步 running 实例？
因为 rsync 同步运行中的 MySQL datadir 是危险操作：InnoDB 的 buffer pool 未刷盘、redo log 处于中间状态、表空间文件可能正被写入——结果是 recipient 启动时必然崩溃，报 ER_INNODB_CORRUPTED_RECORDS 或 ER_LOG_PURGE_UNKNOWN_ERROR。
Clone 插件的价值正在于此：它在 donor 上自动执行 FLUSH TABLES WITH READ LOCK + LOCK INSTANCE FOR BACKUP + redo log 截断 + 拷贝所有 ibd/cfg/trxlog 文件，并确保最终一致性。这是任何外部同步工具无法替代的原子保障。
真正需要关注的，是 donor 锁定期间对业务的影响——尤其大库可能锁数秒至数十秒，建议在低峰期操作，并监控 Performance Schema 中的 clone_progress 表实时观察进度。
