CLONE INSTANCE 能否直接使用取决于插件两端均为 ACTIVE、权限严格分离、配置完全匹配；任一环节缺失将导致卡住、报错或静默失败。
CLONE INSTANCE 能否直接用，取决于插件是否真正就位——不是“装了就行”，而是两端都得 ACTIVE、权限分得清、配置对得上。跳过任一环节，命令就会卡住、报错或静默失败。
确认克隆插件已加载且状态为 ACTIVE
很多问题根源是插件看似装了，实则未激活。动态执行 INSTALL PLUGIN clone SONAME 'mysql_clone.so' 只在当前会话有效，重启即失效。
- 必须在
my.cnf的[mysqld]段添加两行：plugin-load-add = mysql_clone.so和clone = FORCE_PLUS_PERMANENT -
mysql_clone.so必须存在于plugin_dir目录下（查路径用SHOW VARIABLES LIKE 'plugin_dir'） - 两端 MySQL 都要执行
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'clone'，结果必须是ACTIVE；若为空或DISABLED，说明没生效
远程克隆必须配对设置 donor 和 recipient 权限
权限不能混用，也不能复用同一账号不加区分。克隆不是走 SQL 层，REPLICATION SLAVE 在 donor 端完全无效，BACKUP_ADMIN 在 recipient 端也不起作用。
- donor 端用户（如
'cloner'@'192.168.0.101'）只需BACKUP_ADMIN（用于读取物理页） - recipient 端用户（如
'cloner'@'192.168.0.102'）必须有CLONE_ADMIN（隐含SHUTDOWN，因为克隆后会自动重启） - recipient 上还需显式执行：
SET GLOBAL clone_valid_donor_list = '192.168.0.101:3306'（注意：不支持 IPv6、不能带http://） - donor 的
bind_address不能是127.0.0.1，得设为0.0.0.0或具体内网 IP，并放行防火墙 3306 端口
克隆后必须手动重配复制元数据
克隆完的数据目录是 donor 的物理快照，但 server_uuid、gtid_executed、server_id 这些逻辑标识不会自动更新。不处理，主从必然冲突。
- recipient 启动后立刻检查：
SELECT @@server_uuid；若和 donor 相同，删掉auto.cnf让 MySQL 重生成 - 查 donor 的同步位点：
SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status\G，再用它执行CHANGE REPLICATION SOURCE TO ... SOURCE_AUTO_POSITION = 1 -
gtid_mode = ON和enforce_gtid_consistency = ON必须在 donor 端提前开启，否则克隆无法提取有效 GTID 位点 - 克隆后
SHOW SLAVE STATUS必为空，IO/SQL 线程不会自动启动，必须手动START REPLICA（8.0.23+）或START SLAVE
克隆卡住时优先查这三件事
CLONE INSTANCE 卡住 ≠ 失败，大概率是静默等待。别干等，先看实时状态和底层条件。
- 执行
SELECT * FROM performance_schema.clone_status\G，关注STATE和ERROR_NUMBER字段，比命令行提示更准 - 确认 recipient 的
datadir剩余空间 ≥ donor 所有.ibd+ibdata1总大小 × 1.2（克隆过程写日志、临时文件） - 检查 donor 是否满足
innodb_file_per_table = ON；若为 OFF，克隆中途会报ER_CLONE_DONOR_NOT_SUPPORTED - 版本必须完全一致：包括小数点后第三位（如 8.0.33 → 8.0.33），补丁号不同也会触发
ER_CLONE_DONOR_VERSION_MISMATCH
克隆是物理拷贝，不是逻辑复制。所有“自动完成”的预期都要打住——插件不会帮你改 server_id，不会重置 auto_increment_offset，也不会跳过 SELinux 拦截或磁盘权限问题。每一步的校验点，都是上线前必须亲手敲过的命令。
