clone plugin 是物理快照，直接搬运 ibd 文件、脏页和归档 redo，跳过 sql 解析与重放；而 mysqldump 等手工备份需逐行生成、传输、执行 sql，io 和 cpu 开销高，且受字符集、sql mode 等限制。
因为 Clone Plugin 是物理快照，直接搬运 ibd 文件、脏页和归档 redo，完全跳过 SQL 解析与重放；手工备份（如 mysqldump）必须逐行生成、传输、执行 SQL，IO 和 CPU 开销都高得多。
克隆不走 SQL 层，dump 必须走完全部解析链路
MySQL 手工逻辑备份本质是“查数据 → 拼 SQL → 写文件”，恢复时再“读 SQL → 解析语法 → 执行语句 → 写引擎”。中间每一步都串行、不可跳过，且受字符集、SQL mode、函数兼容性等干扰。
Clone Plugin 则在 InnoDB 层截断：它调用 snapshot_copy 接口，让存储引擎直接返回当前一致状态的物理页集合，recipient 收到后仅需做 crash recovery 即可启动——相当于把 donor 的磁盘状态“冷冻搬运”过去。
-
mysqldump --single-transaction仍会触发FLUSH TABLES WITH READ LOCK（元数据锁），阻塞 DDL；Clone 只在最后几秒做轻量同步，源库全程可读写 - dump 输出的是文本 SQL，压缩后体积通常小 30%~50%，但恢复时要重新构建 B+ 树、二级索引、统计信息——这些全是 CPU 密集型操作
- Clone 产出的是原始二进制文件，无法人工审查内容，但启动即用，无重建开销
远程克隆失败常因 recipient 端插件未加载
报错 ERROR 3863 (HY000): Clone not supported 不是网络或权限问题，而是 recipient 实例根本没加载 mysql_clone.so。很多人只在 donor 端配了插件，recipient 还是空跑。
- 两端都必须在
my.cnf的[mysqld]段落加：plugin-load-add = mysql_clone.so和clone = FORCE_PLUS_PERMANENT - Linux 下文件名是
mysql_clone.so，Windows 是mysql_clone.dll，路径写错或权限不足（如 mysqld 用户无读权限）都会静默失败 - 验证命令必须各跑一遍：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'clone'，两台都得返回ACTIVE
克隆后不能直接当从库用，server_uuid 和 gtid 必须手动重置
Clone 是物理拷贝，auto.cnf、gtid_executed、binlog.index 全部原样复制。recipient 启动后若不处理，立刻和 donor 冲突，复制无法建立。
- 启动后第一件事：
SELECT @@server_uuid；如果和 donor 相同，删掉 recipient 的auto.cnf，让 mysqld 重启时重生成 - 查 donor 当前位点：
SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status，拿到后手动执行CHANGE REPLICATION SOURCE TO ... -
clone_valid_donor_list必须设为 global 级：SET GLOBAL clone_valid_donor_list = 'donor_host:3306'；设成 session 级会静默失效
真正容易被忽略的不是命令怎么写，而是克隆后实例的“身份残留”——它看起来是新节点，实际带着 donor 的心跳 ID 和事务指纹。不清理 auto.cnf、不重置 gtid_purged、不手动配置复制起点，克隆就只是个能连上的空壳。
