CLONE INSTANCE 仅支持远程克隆，本地克隆必须使用 CLONE LOCAL DIRECTORY；因其设计禁止 donor 与 recipient 为同一 MySQL 进程，即使使用 127.0.0.1 也会因循环检测、权限校验或 super_read_only 限制而失败，而 CLONE LOCAL DIRECTORY 则通过物理拷贝在本机安全完成克隆。
CLONE INSTANCE 不能用于本地克隆——它只支持远程克隆，本地克隆必须用 CLONE LOCAL DIRECTORY。
为什么 CLONE INSTANCE 在本机执行会失败
很多人误以为 CLONE INSTANCE 可以在本机对同一实例做“自克隆”，实际它设计上就是面向跨实例（即 donor/recipient 分离）的网络克隆。当你在源实例上执行 CLONE INSTANCE FROM 'u'@'127.0.0.1':3306，MySQL 会尝试建立新连接去读取自己，但会触发循环检测或权限校验失败，常见报错包括：
ERROR 3095 (HY000): The cloning operation failed: Donor connection rejected-
ERROR 1792 (HY000): Cannot execute statement in a READ ONLY transaction（尤其在super_read_only=ON时） - 或静默卡在
Stage: clone_type，performance_schema.clone_status显示无进展
根本原因：MySQL 不允许 donor 和 recipient 是同一个 MySQL 进程；即使 IP 是 127.0.0.1，只要端口相同、进程 PID 相同，就视为非法。
CLONE LOCAL DIRECTORY 才是本地克隆的唯一合法命令
本地克隆本质是“把当前实例的数据文件，物理拷贝到服务器上另一个目录”，不走网络、不启新连接，全程由 mysqld 自己完成。它要求：
- 目标路径必须**不存在**（MySQL 会自动创建），且不能位于
datadir内部（否则报Directory overlaps with data directory） - mysqld 进程用户（如
mysql）对该路径有完整读写权限：chown -R mysql:mysql /backup/clone_202405 - 执行用户需具备
BACKUP_ADMIN权限（REPLICATION SLAVE不够） - 克隆过程中实例仍可提供服务，但会显著增加 I/O 和缓冲池压力
示例操作：
mysql> CLONE LOCAL DIRECTORY = '/backup/clone_20260507';
成功后，该目录下会生成完整 datadir 结构（含 ibdata1、mysql 系统库、所有 .ibd 文件等），可直接作为新实例的 datadir 启动。
本地克隆后启动新实例的关键动作
克隆出的目录是“裸数据”，不能直接 mysqld --datadir=/backup/clone_20260507 就跑起来——缺两个关键文件：
-
auto.cnf：必须删除。否则新实例启动时复用原server-uuid，导致 GTID 冲突或复制异常 -
binlog.*和relay-log.*：建议一并清理，避免被误读为旧日志
此外，若要将该克隆目录作为独立从库使用，还需手动配置 my.cnf 中的 server-id（必须全局唯一）、gtid_mode=ON、enforce_gtid_consistency=ON，再通过 CHANGE REPLICATION SOURCE TO 设置主库信息。
别忽略磁盘与参数限制
本地克隆不是“复制粘贴”那么简单，几个硬性条件不满足就会卡死或失败：
- 目标路径所在磁盘剩余空间 ≥ 源库
ibdata1+ 所有.ibd总大小 × 1.2（克隆过程产生临时日志和校验文件） - 源库必须开启
innodb_file_per_table = ON；否则报ER_CLONE_DONOR_NOT_SUPPORTED - 目标路径不能是 NFS 或其他网络文件系统（Clone 插件不支持，会报
Invalid argument） - 若用
SET GLOBAL clone_max_concurrency = 2降并发缓解 I/O 压力，需确认变量已动态生效（SELECT @@clone_max_concurrency）
真正麻烦的从来不是命令敲不对，而是克隆前没检查 auto.cnf 是否残留、server-id 是否冲突、磁盘是否真够用——这些细节一漏，实例就起不来，还得翻日志逐行 debug。
