MySQL 8.0.17+才支持CLONE插件，必须版本≥8.0.17、插件状态为ACTIVE、配置持久化、分端授权（donor需BACKUP_ADMIN，recipient需CLONE_ADMIN）、设clone_valid_donor_list、克隆后删除auto.cnf防UUID冲突。
CLONE 插件不是“装上就能用”的功能，它对版本、权限、配置、网络和文件系统都有硬性要求。MySQL 8.0.17+ 才真正支持远程克隆，低于该版本或配置错一步，CLONE INSTANCE 就会静默卡住、报错退出，甚至删光目标数据。
确认 MySQL 版本与插件状态是否为 ACTIVE
很多失败从第一步就埋下了：你以为插件已启用，其实只是 INSTALL PLUGIN 过但没持久化，或者版本根本不够。
- 执行
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'clone';—— 必须返回ACTIVE；若为空或DISABLED，说明未加载 - 检查版本：
SELECT VERSION();必须 ≥8.0.17；8.0.27 之前不支持并发 DDL，克隆时源库所有 DDL 会被阻塞 - 动态安装仅临时有效：
INSTALL PLUGIN clone SONAME 'mysql_clone.so';（Linux）或INSTALL PLUGIN clone SONAME 'mysql_clone.dll';（Windows） - 永久生效必须写进
my.cnf的[mysqld]段：plugin-load-add = mysql_clone.so<br>clone = FORCE_PLUS_PERMANENT
否则重启后插件丢失，CLONE命令直接报Unknown command 'CLONE'
本地克隆 vs 远程克隆：别用错命令模式
误把 CLONE LOCAL DATA DIRECTORY 当成扩容手段，会清空目标路径下所有文件（包括非 MySQL 数据）；而用 CLONE INSTANCE FROM 却没配 donor 白名单，又会连不上。
- 本地克隆只适用于同一台机器新建实例：
CLONE LOCAL DATA DIRECTORY = '/data/clone_20260609';—— 目标路径必须不存在，且属主为mysql:mysql，否则报Permission denied - 远程克隆才是迁移主力：
CLONE INSTANCE FROM 'clone_donor'@'192.168.0.101':3306 IDENTIFIED BY 'pwd';—— 注意用户是 donor 端的账号，不是当前登录账号 - 远程克隆前，recipient 必须先设白名单：
SET GLOBAL clone_valid_donor_list = '192.168.0.101:3306';（不能带http://，IPv6 不支持） - donor 的
bind_address不能是127.0.0.1，得设为0.0.0.0或具体内网 IP，并放行防火墙/SELinux
权限必须分端配置，不能复用一个账号
克隆不走 SQL 层，REPLICATION SLAVE 权限完全无效；用错权限，认证阶段就会卡死或报 ERROR 3095 (HY000): Insufficient privileges。
- donor（源库）用户只需：
GRANT BACKUP_ADMIN ON *.* TO 'clone_donor'@'%'; - recipient（目标库）用户必须有：
GRANT CLONE_ADMIN ON *.* TO 'clone_recip'@'%';（该权限隐含SHUTDOWN，因为克隆后会自动重启 mysqld） - 不要给同一个账号同时授
BACKUP_ADMIN和CLONE_ADMIN——权限混淆易导致 donor 认证失败 - donor 用户密码需明文一致，且 donor 必须允许从 recipient 主机 IP 连入（如
'clone_donor'@'192.168.0.102'更安全）
克隆后必须手动处理 auto.cnf 和 server_uuid
克隆是物理快照，auto.cnf 里的 server-uuid 会原样复制过去。如果不删，新实例启动时因 UUID 冲突直接拒绝服务，或后续配主从时报 GTID_PURGED conflict。
- 克隆完成后，recipient 的 MySQL 会自动退出并由 systemd/mysqld_safe 拉起；此时立刻停服务：
systemctl stop mysqld - 删除
/var/lib/mysql/auto.cnf（或你的datadir下对应文件），让 MySQL 重启时重生成唯一server-uuid - 检查
SELECT @@server_uuid;是否已变更；再查SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status;获取 donor 的 binlog 位点，用于后续主从配置 -
innodb_file_per_table=OFF的旧实例无法被克隆；目标端若仍启用该模式，会触发Invalid tablespace file
克隆不是“一键复制”，它是物理层操作，依赖底层文件系统支持硬链接（ext4/xfs）、两端参数对齐（如 innodb_log_file_size）、以及 donor 的 redo 日志持续可读。最容易被跳过的动作——删 auto.cnf、设 clone_valid_donor_list、分端赋权——恰恰是生产环境失败率最高的环节。
