必须确保PLUGIN_STATUS为ACTIVE，否则CLONE命令报错或静默失败；动态安装仅会话生效，永久启用需在my.cnf中配置plugin-load-add=mysql_clone.so和clone=FORCE_PLUS_PERMANENT并重启mysqld。
克隆插件不是装上就能用，必须确保 PLUGIN_STATUS 是 ACTIVE，否则所有后续操作都会静默失败或报错 Unknown command 'CLONE'。
确认 clone 插件已永久启用且状态为 ACTIVE
很多“克隆失败”其实卡在插件根本没加载。动态执行 INSTALL PLUGIN clone SONAME 'mysql_clone.so'; 只对当前会话有效，MySQL 重启后就失效。
- 登录后第一件事：运行
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'clone';，结果中PLUGIN_STATUS必须是ACTIVE - 永久生效需修改
my.cnf（Linux）：[mysqld] plugin-load-add = mysql_clone.so clone = FORCE_PLUS_PERMANENT
- 改完必须
systemctl restart mysqld；reload不触发插件重载 - 检查
SELECT @@plugin_dir;返回路径下是否存在mysql_clone.so，且 MySQL 启动用户有读+执行权限（chmod 755） - SELinux 或 AppArmor 可能拦截加载，临时用
setenforce 0验证是否为此类问题
远程克隆必须 donor 和 recipient 双向配齐权限与网络
远程克隆不是 recipient 单方面发起就能连上的操作。donor 和 recipient 各自要满足三件事：插件启用、权限正确、网络通路打开——漏掉任意一个，都会静默卡住或报错 ERROR 3864 (HY000): Clone Donor connection failed。
- donor 端用户（如
'cloner'@'192.168.0.101'）需BACKUP_ADMIN；recipient 端用户（如'cloner'@'localhost'）需CLONE_ADMIN（注意：不是同一个账号，也不能复用复制账号） - 账号必须在 donor 和 recipient 上都存在、密码一致，且执行
GRANT后要FLUSH PRIVILEGES - donor 的
bind_address不能是127.0.0.1，得设为0.0.0.0或具体内网 IP，并确保防火墙放行 3306 端口 - recipient 必须提前执行：
SET GLOBAL clone_valid_donor_list = '192.168.0.101:3306';（不能带http，也不能写成域名未解析的主机名）
执行 CLONE INSTANCE 前的关键检查项
克隆命令看似简单，但实际执行前有四个硬性条件缺一不可：版本一致、权限分治、配置对齐、网络可达。跳过任一检查，CLONE INSTANCE 就会卡住、静默失败或报错后退出。
- MySQL 版本必须完全一致（包括小版本号），例如 donor 是
8.0.29，recipient 也必须是8.0.29 -
innodb_file_per_table必须两端都为ON；否则克隆后启动失败，报错Tablespace is missing - recipient 的
datadir必须为空目录（不能只含.keep文件），且磁盘剩余空间 ≥ donor 当前datadir实际占用（用du -sh /var/lib/mysql查看） - 克隆完成后 recipient 会自动重启，但
auto.cnf中的server-uuid会被保留——这点极易被忽略，若不手动更新，后续配置主从时会因 UUID 冲突拒绝连接
克隆后必须手动配置复制参数并校验 GTID 位置
克隆插件不复制配置、不复制 binlog 文件，只提取并写入复制坐标（binlog filename/position 或 gtid_executed）。这意味着 recipient 启动后仍是“裸实例”，必须立刻补全复制链路。
- 克隆完成、recipient 重启后，立即查位置：
SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status; - 或查 GTID：
SELECT @@GLOBAL.GTID_EXECUTED; - 然后执行
CHANGE REPLICATION SOURCE TO ...，注意用你的复制账号（如'repl'@'%'），不是克隆账号 - 关键点：donor 的 binlog 不能在克隆后、启动复制前被 purge，否则报错
Could not find first log file name in binary log index file
最常被跳过的其实是 server-uuid 更新和 clone_valid_donor_list 的显式设置——前者导致复制无法建立，后者让克隆命令直接找不到 donor，而错误信息往往模糊到难以定位。
