MySQL克隆插件通过物理快照（InnoDB数据页+redo归档）绕过SQL层重放，实现秒级TB级迁移；需donor与recipient两端均启用clone插件、配置一致参数，并正确赋权BACKUP_ADMIN/CLONE_ADMIN。
因为克隆是物理快照，跳过了 SQL 层重放，直接复制 InnoDB 数据页和 redo 归档，避免了传统复制中拉取、解析、执行海量 binlog 的耗时过程。
克隆不走复制通道，而是直接搬运物理页
MySQL 主从或 MGR 节点加入时，传统方式依赖 binlog 位点做分布式恢复：先找起始位置，再逐条拉取、反解、应用——数据量大时可能卡在 I/O 或解析瓶颈上。Clone Plugin 完全绕开这一层：CLONE INSTANCE 触发后，donor 端按 [INIT] → [FILE COPY] → [PAGE COPY] → [REDO COPY] 四阶段推进，把 ibd 文件、脏页、归档 redo 一并传给 recipient，recipient 收完直接做 crash recovery 启动，等效于“把 donor 当前时刻的磁盘状态完整搬过来”。
常见错误现象：误以为克隆需要 REPLICATION SLAVE 权限，结果报 ERROR 3095 (HY000): Insufficient privileges；实际 donor 只需 BACKUP_ADMIN（读物理页），recipient 必须有 CLONE_ADMIN（隐含 SHUTDOWN，因克隆后要自动重启）。
远程克隆必须两端都配对生效，缺一不可
很多人只在 donor 端装插件，recipient 执行 CLONE INSTANCE 就报 ERROR 3863 (HY000): Clone not supported。根本原因是：recipient 本地没加载 mysql_clone.so，无法解析和响应克隆协议。
- 两端都要在
my.cnf的[mysqld]段落加：plugin-load-add = mysql_clone.so和clone = FORCE_PLUS_PERMANENT - Linux 下文件名是
mysql_clone.so，Windows 是mysql_clone.dll，路径写错会导致加载失败 - 验证命令必须在两台机器都跑：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'clone'，都得返回ACTIVE
克隆后不能直接当从库用，server_uuid 和 gtid 必须重置
克隆是物理拷贝，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 级变量，recipient 上必须用SET GLOBAL clone_valid_donor_list = 'donor_host:3306'，设成 session 级会静默失效
真正容易被忽略的是配置一致性：recipient 的 innodb_page_size、innodb_log_file_size 等底层参数必须和 donor 完全一致，否则克隆完启动就报错退出——这些值不会被克隆覆盖，但会影响数据文件加载。
