mysql 8.0 clone插件通过直接拷贝innodb物理文件、redo日志及gtid位点实现秒级克隆，非sql复制或binlog重放；静默卡住或报error 3864主因是插件未激活、clone_valid_donor_list未设、donor bind_address配置不当、网络端口阻塞，或权限/账号配置错误；克隆后需手动清理auto.cnf、重设server_id并启用binlog才能配主从。
MySQL 8.0 的 CLONE 插件不是“复制 SQL”或“重放 binlog”，而是直接拷贝 InnoDB 物理文件（包括 ibdata1、ib_logfile*、表空间文件、redo 日志）、数据字典元数据和 GTID 执行位点，生成一个可立即启动的完整数据目录。它本质是物理快照，不是逻辑同步。
为什么 CLONE INSTANCE 会静默卡住或报 ERROR 3864
这不是网络连通性问题本身，而是 donor 和 recipient 双向校验失败后主动中止的表现。常见原因有：
-
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'clone';在任一端返回空或DISABLED—— 插件未真正加载 - recipient 未执行
SET GLOBAL clone_valid_donor_list = '192.168.0.101:3306';（注意不能带http://，不能用127.0.0.1） - donor 的
bind_address是127.0.0.1，导致 recipient 无法建立 TCP 连接 - 防火墙/SELinux/云安全组未放行 donor 的 3306 端口（注意：不是 recipient 的端口）
CLONE LOCAL DATA DIRECTORY 和 CLONE INSTANCE FROM 的权限差异
两者走完全不同的权限路径，不能混用账号或复用权限：
-
CLONE LOCAL DATA DIRECTORY只需当前登录用户拥有BACKUP_ADMIN；目标路径必须不存在，且mysqld进程属主（通常是mysql:mysql）对该路径有写权限 -
CLONE INSTANCE FROM要求：donor 端用户（如'clone_donor'@'192.168.0.101'）必须有BACKUP_ADMIN+REPLICATION SLAVE；recipient 端用户（如'clone_recip'@'localhost'）必须有CLONE_ADMIN（该权限隐含SHUTDOWN，克隆后会自动重启） - recipient 上的
CLONE_ADMIN用户不能是 donor 端的同名账号，也不能是'root'@'%'这类宽泛账号——必须显式创建并限定 host
克隆完成后为什么不能直接配主从
因为 CLONE 只复制了数据文件和 GTID_EXECUTED 值，不写 master.info、不设置 source_host、不启动 IO_THREAD / SQL_THREAD，更不会继承 donor 的 server_id 或 binlog_format 配置：
- recipient 克隆后自动重启，但
my.cnf中的server_id若未提前设好，会导致后续CHANGE REPLICATION SOURCE TO失败 - 必须手动执行
rm -f /var/lib/mysql/auto.cnf，否则server_uuid冲突，START REPLICA直接拒绝连接 - 克隆时 donor 的 binlog 位点（
BINLOG_FILE/BINLOG_POSITION）会被记录在performance_schema.clone_status中，但 recipient 不会自动启用 binlog；若要作为从库，需确认log_bin=ON已开启
最易被忽略的是：克隆完成后的 auto.cnf 清理和 server_id 配置，这两步缺失，主从永远启不来——不是性能问题，是元数据冲突。
