本地克隆是误删后快速恢复的唯一可行方式，5–30秒生成可启动快照，donor在线无影响；远程克隆仅适用于扩容从库，需清空recipient并手动处理server-uuid与server_id。
本地克隆是唯一可用于误删后快速恢复的路径，远程克隆本质是覆盖式重建，必须停业务、重配主从，不能当“恢复”用。
确认 clone 插件状态为 ACTIVE
插件装了不等于能用，很多报错卡在这一步。执行 SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'clone';，结果中 PLUGIN_STATUS 必须是 ACTIVE。
若为 DISABLED：检查 @@plugin_dir 下是否存在 mysql_clone.so（Linux）或 mysql_clone.dll（Windows），MySQL 启动用户需有读+执行权限（chmod 755）；SELinux 或 AppArmor 可能拦截，临时用 setenforce 0 验证。
若查不到记录：说明插件根本没加载，my.cnf 中必须写明：[mysqld]plugin-load-add = mysql_clone.soclone = FORCE_PLUS_PERMANENT
本地克隆：5–30 秒生成可启动快照
这是真正用于误删/故障后应急恢复的唯一可行方式。donor 实例全程在线，不影响业务。
- 执行前确保 donor 用户有
BACKUP_ADMIN权限（不需要REPLICATION SLAVE或CLONE_ADMIN） - 目标目录必须为空，且 MySQL 进程对其有读写权限：
chown mysql:mysql /backup/clone_20260902 - 命令示例：
CLONE LOCAL DATA DIRECTORY = '/backup/clone_20260902'; - 完成后得到一个完整、冷态、可直接启动的副本目录；原 donor 实例不受任何影响
恢复时只需停掉出问题的实例，重命名原 datadir，mv 克隆目录过去，chown mysql:mysql，再启动 mysqld 即可。
远程克隆：只适合扩容从库，不是恢复方案
远程克隆会清空 recipient 数据目录并完全替换，整个过程 recipient 不可用，且克隆后必须手动处理 auto.cnf 和 server_id，否则无法启动复制。
- donor 用户需同时具备
BACKUP_ADMIN+REPLICATION SLAVE；recipient 用户必须是CLONE_ADMIN（仅BACKUP_ADMIN会报ERROR 3095） - 两端账号必须同名同密，且都存在；
bind_address不能是127.0.0.1，得设为0.0.0.0或内网 IP，并放行 3306 端口 - recipient 上必须提前设置：
SET GLOBAL clone_valid_donor_list = '192.168.1.10:3306';（格式严格：IP:PORT，不带协议） - 克隆完成后 recipient 自动退出重启，但
auto.cnf中的server-uuid会被保留——必须手动删掉它，让 mysqld 启动时自动生成新值；再连进去执行SET GLOBAL server_id = 新值
克隆后 server-uuid 冲突是最容易被忽略的致命点
无论本地还是远程克隆，只要目标实例要参与主从或 Group Replication，就必须处理 server-uuid。克隆操作不会覆盖 auto.cnf，而重复的 server-uuid 会导致：
— 主从同步直接拒绝连接（Got fatal error 1236 from master）
— GTID 复制事务无法识别来源
— performance_schema 监控项异常
正确做法：克隆完成后，在 recipient 数据目录里删掉 auto.cnf，再启动 mysqld；它会自动生成新 server-uuid；之后再进库执行 SET GLOBAL server_id = ...（不能为 0 或与其他节点重复）。
