MySQL克隆插件远程克隆必须满足版本一致、权限分治（donor需BACKUP_ADMIN+REPLICATION SLAVE，recipient需CLONE_ADMIN）、配置对齐（server-uuid、binlog等需手动配置）、网络可达（bind_address非127.0.0.1且3306端口开放），且插件状态必须为ACTIVE，缺一不可。
能，但必须版本一致、权限分治、配置对齐、网络可达——缺一不可。跳过任一检查，CLONE INSTANCE 就会卡住、报错或静默失败。
确认 clone 插件状态为 ACTIVE 而非 DISABLED 或空
很多人执行了 INSTALL PLUGIN clone SONAME 'mysql_clone.so' 就以为装好了，结果命令没反应或报错 ER_CLONE_DONOR_NOT_FOUND。关键不是“装了”，而是“活的”。
- 必须运行
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'clone'，返回的PLUGIN_STATUS必须是ACTIVE - 若为
DISABLED：常见原因是mysql_clone.so文件不在@@plugin_dir目录下，或 MySQL 启动用户对该文件无读+执行权限（chmod 755） - 若查不到记录：说明插件根本没加载，
my.cnf中需明确写plugin-load-add = mysql_clone.so，且不能漏掉等号；升级后首次启动不能直接加该配置，得先正常启一次再重启生效
远程克隆必须 donor 和 recipient 权限分离且账号双端存在
克隆不走复制权限体系，REPLICATION SLAVE 或 BACKUP_ADMIN 单独给都不够用，混用账号更会直接失败。
- donor（源库）用户（如
'cloner'@'192.168.1.10'）必须有：BACKUP_ADMIN（必需）、REPLICATION SLAVE（后续配主从用） - recipient（目标库）用户（同名同密）必须有：
CLONE_ADMIN（隐含BACKUP_ADMIN+SHUTDOWN），仅授BACKUP_ADMIN会报ERROR 3095 (HY000): Insufficient privileges - recipient 上还需提前执行：
SET GLOBAL clone_valid_donor_list = '192.168.1.10:3306'（注意格式：IP:PORT，不能带协议，不能用域名除非 DNS 稳定且两端都认） - donor 的
bind_address不能是127.0.0.1，得设为0.0.0.0或具体内网 IP，并确保防火墙放行 3306 端口
CLONE INSTANCE 执行后自动重启，但 server-uuid 和复制配置全丢失
这是设计行为，不是异常——但也是最容易被忽略的断点。克隆完 recipient 实例会退出并由 systemd/mysqld_safe 拉起，数据是新的，配置却是旧的。
-
auto.cnf中的server-uuid不会被覆盖，必须手动改掉，否则后续CHANGE REPLICATION SOURCE TO会因 UUID 冲突拒绝连接 -
gtid_executed是 donor 克隆时刻的快照值，但log_bin、binlog_format、server_id等关键配置不会复制，需提前在 recipient 的my.cnf中配好 -
SHOW SLAVE STATUS必为空，必须手动执行CHANGE REPLICATION SOURCE TO SOURCE_HOST='x.x.x.x', SOURCE_USER='repl', SOURCE_PASSWORD='xxx', SOURCE_AUTO_POSITION=1 - 克隆过程会上短暂全局读锁（毫秒级），但 donor 仍可读写；recipient 的
datadir必须为空且支持硬链接，磁盘剩余空间建议 ≥ 源库ibdata1+ 所有.ibd总大小 × 1.2
真正麻烦的从来不是命令本身，而是那些不报错却让复制起不来的细节：比如 server-uuid 没改、clone_valid_donor_list 漏设、或者两边 innodb_file_per_table 开关不一致导致中途报 Invalid tablespace file。这些点不提前扫清，CLONE INSTANCE 表面成功，实则埋雷。
