必须删除auto.cnf并重置server_uuid，否则克隆后因UUID冲突导致复制连接被静默拒绝；需确认clone插件状态为ACTIVE， donor与recipient分设BACKUP_ADMIN/CLONE_ADMIN权限，且recipient须预设clone_valid_donor_list白名单。
能，但必须用对权限、配对设白名单、删掉 auto.cnf 里的旧 server_uuid，否则克隆完立刻连不上主库——这不是网络问题，是 UUID 冲突导致的静默拒绝。
确认 clone 插件状态为 ACTIVE，不是 DISABLED 或空
很多失败卡在这一步：执行了 INSTALL PLUGIN clone SONAME 'mysql_clone.so' 就以为装好了，结果 CLONE INSTANCE 报错或卡住不动。关键要看真实状态：
- 必须运行
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'clone'，返回的PLUGIN_STATUS必须是ACTIVE - 若为
DISABLED：常见原因是mysql_clone.so文件不在@@plugin_dir目录下，或 MySQL 启动用户对该文件无读+执行权限（chmod 755） - 若查不到记录：说明插件根本没加载，
my.cnf中需明确写plugin-load-add = mysql_clone.so，且不能漏等号；升级后首次启动不能直接加该配置，得先正常启一次再重启生效
donor 和 recipient 权限必须分设，不能复用一个账号
克隆不走 REPLICATION SLAVE 权限体系，源和目标要各自授权，且账号必须在两端都存在、密码一致：
- donor（主库）上用户（如
'cloner'@'192.168.30.210'）必须有：BACKUP_ADMIN（必需）、REPLICATION SLAVE（后续配主从用） - recipient（从库）上同名用户（如
'cloner'@'192.168.30.211'）必须有：CLONE_ADMIN（隐含SHUTDOWN，因克隆完要自动重启），只给BACKUP_ADMIN不行 - 两边执行
GRANT后都必须FLUSH PRIVILEGES，否则权限不生效 - recipient 上还必须提前运行：
SET GLOBAL clone_valid_donor_list = '192.168.30.210:3309'（注意端口匹配，别填错）
克隆完成后必须手动处理 server_uuid 和复制配置
克隆是物理拷贝，auto.cnf 原样复制，导致 server_uuid 冲突，后续 CHANGE REPLICATION SOURCE TO 会直接拒绝连接：
- recipient 重启后第一件事：
rm -f /var/lib/mysql/auto.cnf（Linux 路径，Windows 是 datadir 下同名文件） - 重启 MySQL，检查
SELECT @@server_uuid，确认与 donor 不同；若相同，说明auto.cnf没删干净 -
my.cnf中必须提前配好：server_id唯一、gtid_mode = ON、log_bin开启（否则无法做主从） - 克隆只复制
gtid_executed快照值，不写master.info、不启动复制线程，必须手动执行：CHANGE REPLICATION SOURCE TO SOURCE_HOST='192.168.30.210', SOURCE_USER='repl', SOURCE_PASSWORD='xxx', SOURCE_AUTO_POSITION=1
最容易被忽略的是 auto.cnf 未清理和 clone_valid_donor_list 白名单未设——这两处出错不会报明显错误，而是让克隆成功但后续复制完全无法建立。
