插件状态为DISABLED说明加载失败，常见原因有三：plugin_dir下缺失mysql_clone.so文件、MySQL进程用户缺少该文件执行权限、SELinux拦截动态库加载。
克隆前插件状态是 DISABLED，根本走不到执行阶段
执行 INSTALL PLUGIN clone SONAME 'mysql_clone.so' 后查 INFORMATION_SCHEMA.PLUGINS 发现状态仍是 DISABLED，不是命令写错了，而是底层加载失败但没抛显式错误。常见原因有三个：
• plugin_dir 指向的路径下压根没有 mysql_clone.so 文件，先用 ls -l $MYSQL_HOME/lib/plugin/mysql_clone.so 确认存在；
• MySQL 进程启动用户（如 mysql）对 mysql_clone.so 缺少执行权限，chmod 755 补上；
• SELinux 启用状态下会拦截动态库加载，临时验证可 setenforce 0，长期要用 audit2allow 生成策略。
CLONE INSTANCE 报 ERROR 3095：权限配置错位
插件状态是 ACTIVE，但一执行 CLONE INSTANCE 就报 ERROR 3095 (HY000): Insufficient privileges，问题不在命令本身，而在角色分配逻辑被很多人搞反：
• 捐赠者（donor，即源库）上的用户必须有 BACKUP_ADMIN 权限；
• 接收者（recipient，即目标库）上的用户必须有 CLONE_ADMIN 权限；
• 两者不能复用同一个账号而不分别授权——哪怕你用的是 root，也得显式执行 GRANT CLONE_ADMIN ON *.* TO 'clone_user'@'%' 在 recipient 上。
克隆后无法登录或复制启动失败
克隆成功、MySQL 也重启起来了，但 mysql -u root -p 连不上，或者 START SLAVE 报 GTID 冲突，本质是克隆只拷二进制文件，不处理元数据兼容性：
• mysql.user 表里 caching_sha2_password 用户记录在新实例可能因客户端不支持而认证失败，需手动执行 ALTER USER 'u'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd'；
• 源库和 recipient 的 server_uuid 相同会导致 GTID_PURGED 冲突，虚拟机克隆环境务必改掉 recipient 的 server_uuid；
• 克隆不带 binlog 位置自动同步逻辑，得靠插件自己提取并设置，若失败需检查 donor 是否启用了 log_bin 且 binlog_format=ROW。
克隆中途卡住或报 too many concurrent clone operations
远程克隆过程中突然不动，或者日志里反复出现 too many concurrent clone operations，这不是网络或磁盘问题，而是并发控制机制触发了保护：
• clone_max_concurrency 默认值是 4，如果 donor 或 recipient 正在跑大量 DDL 或备份锁未释放，克隆线程会被阻塞；
• 不要调高 clone_max_concurrency 硬扛，先确认 donor 上没其他 CLONE 或 BACKUP 操作在运行；
• 若 recipient 是刚装好的空实例，检查是否残留旧数据目录——克隆默认会清空 datadir，但若目录非空且权限混乱，可能卡在清理阶段无提示。
克隆不是“一键复制”，最常被跳过的其实是 recipient 启动后的三件事：改 server_uuid、重置关键用户的认证方式、确认 gtid_purged 值与 donor 一致。这些动作不写在任何 CLONE 命令里，但缺一不可。
