必须确认克隆插件状态为ACTIVE：执行SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'clone';，结果中PLUGIN_STATUS须为ACTIVE而非DISABLED或空；若为DISABLED，需检查my.cnf配置或plugin_dir路径是否正确。
MySQL 8.0 的 CLONE INSTANCE 是目前最直接、最省时的从库扩容方式——它不依赖备份恢复，也不走复制追日志，而是直接传输物理数据快照。但配置稍有偏差，命令就会报错或静默失败。
如何确认克隆插件已正确加载
插件状态不是“安装了”就等于“能用”，必须检查是否处于 ACTIVE 状态，且不能被其他插件冲突屏蔽。
- 执行
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'clone';，输出中PLUGIN_STATUS必须为ACTIVE，不是DISABLED或空 - 若为
DISABLED，优先检查my.cnf中是否误加了plugin-load-add=mysql_clone.so但没配clone=FORCE_PLUS_PERMANENT；动态安装后未重启也可能导致状态不稳定 -
mysql_clone.so文件必须真实存在于plugin_dir路径下（可用SELECT @@plugin_dir;查看），否则INSTALL PLUGIN会报Can't open shared library
远程克隆前必须设置 clone_valid_donor_list
这是最容易被跳过的一步：从库（recipient）在执行 CLONE INSTANCE 前，必须显式告诉 MySQL “只允许从哪些地址拉取数据”，否则直接报错 ER_CLONE_DONOR_NOT_ALLOWED。
- 在 recipient 上执行：
SET GLOBAL clone_valid_donor_list = '192.168.56.201:3306';（注意格式是IP:PORT，不能带协议、不能写域名，除非 DNS 解析稳定且被 donor/recipient 同时认可） - 该变量是 session 级别无效的，必须用
GLOBAL；且仅对后续的CLONE INSTANCE生效，不影响其他操作 - 如果 donor 是多实例共存（如多个端口），需全部列出，用逗号分隔：
'192.168.56.201:3306,192.168.56.201:3307'
CLONE INSTANCE 执行时的关键权限与用户隔离
donor 和 recipient 对同一账号的权限要求不同，混用会导致 Access denied 或克隆中断。
- donor 上的克隆用户（如
clone_user@'%'）必须有BACKUP_ADMIN，否则报ERROR 3037 (HY000): Operation not allowed - recipient 上执行
CLONE INSTANCE的用户，必须有CLONE_ADMIN；如果复用 donor 用户，需提前在 recipient 上也授此权限：GRANT CLONE_ADMIN ON *.* TO 'clone_user'@'%'; - donor 和 recipient 的
server_uuid必须不同，否则克隆完成后启动复制会报GTID_PURGED conflict；虚拟机克隆环境务必手动改server_uuid
克隆完成后必须手动重建复制关系
克隆插件会把 donor 的 GTID_EXECUTED 和 binlog 位置写入 recipient 的 performance_schema.clone_status，但它**不会自动执行 CHANGE MASTER TO**。
- 克隆完成后 recipient 实例会自动重启，重启后立刻查：
SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status;和SELECT @@GLOBAL.GTID_EXECUTED; - 用查到的值执行
CHANGE MASTER TO MASTER_AUTO_POSITION = 1（推荐）或MASTER_LOG_FILE/MASTER_LOG_POS；注意MASTER_HOST要填 donor 的可连通 IP，不是localhost - 如果 donor 开启了
require_row_format或 binlog 格式不一致，START SLAVE可能卡在Waiting for source to send event，此时要核对双方binlog_format是否均为ROW
真正容易被忽略的是：克隆过程会清空 recipient 的整个数据目录（除非你用本地克隆+指定路径），而且这个动作不可逆——没有“取消克隆”或“回滚到克隆前”的机制。执行前务必确认 datadir 下无任何不可丢失的文件，包括自定义的 slow_log、general_log 或第三方监控生成的临时表空间。
