MySQL克隆操作卡顿90%源于插件未永久激活、权限错配或路径已存在；需在my.cnf中配置plugin-load-add与clone=FORCE_PLUS_PERMANENT并重启服务，且远程克隆须双向配置权限、白名单及SSL要求，本地克隆则要求目标路径不存在、属主正确、空间充足，克隆后必须删除auto.cnf避免server_uuid冲突。
“秒级”只适用于 GB 级数据（如 2–5 GB），TB 级实际耗时数分钟到数十分钟；真正卡住你的，90% 不是网络或磁盘，而是插件没真正加载、权限错配或路径已存在。
确认 clone 插件已永久激活且状态为 ACTIVE
动态执行 INSTALL PLUGIN clone SONAME 'mysql_clone.so' 只是临时生效，MySQL 重启即失效。必须在 my.cnf 的 [mysqld] 段添加两行：
-
plugin-load-add = mysql_clone.so（Linux）或plugin-load-add = mysql_clone.dll（Windows） clone = FORCE_PLUS_PERMANENT
改完配置必须 systemctl restart mysqld；reload 不触发插件重载。登录后立刻验证：
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）。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
远程克隆必须 donor/recipient 双向配齐权限与白名单
远程克隆不是 recipient 单方面发起就能连上的操作。漏掉任意一端的任一条件，都会静默卡住或报 ERROR 3864 (HY000): Clone Donor connection failed 或 ERROR 3095 (HY000): Insufficient privileges。
- donor 端用户（如
'cloner'@'192.168.0.101'）需同时具备：BACKUP_ADMIN（必需）、REPLICATION SLAVE（后续配主从用） - recipient 端用户（如
'cloner'@'localhost'）必须有CLONE_ADMIN（该权限隐含BACKUP_ADMIN+SHUTDOWN），不能复用复制账号或只给BACKUP_ADMIN - recipient 必须提前执行：
SET GLOBAL clone_valid_donor_list = '192.168.0.101:3306'（地址必须精确到 IP+端口，不能带http或域名） - 两端用户账号需真实存在、密码一致；若启用 SSL，还需双方
require_secure_transport=ON时同步配置REQUIRE SSL
本地克隆失败几乎全是目录权限或空间问题
CLONE LOCAL DATA DIRECTORY 不是“复制到已有目录”，而是清空目标路径、重建整个数据目录结构。哪怕路径下只有一行 .keep 文件，也会失败。
- 目标路径必须**不存在**：
/data/clone_20261105✅，/data/mysql❌，/data/clone_20261105/（末尾斜杠不关键，但路径不能已存在）❌ - 创建后立即执行：
chown -R mysql:mysql /data/clone_20261105，只改父目录属主不够，子目录和文件也要递归归属 - 磁盘剩余空间必须 ≥ 当前
datadir实际占用（用du -sh /var/lib/mysql看），CLONE不压缩、不去重 - 执行命令格式严格：
CLONE LOCAL DATA DIRECTORY = '/data/clone_20261105';（等号可省略，但路径必须是绝对路径、单引号包裹）
克隆完成后不能直接当从库启动？检查 auto.cnf 和 server_uuid
克隆是物理拷贝，auto.cnf、gtid_executed、binlog_index 这些逻辑元数据原样复制。recipient 启动后若不处理，立刻和 donor 冲突：
- 启动前必须删掉其中的
auto.cnf，否则server_uuid冲突导致无法启动 -
CLONE INSTANCE执行后 recipient 会自动重启，但my.cnf中的server_id若未提前设好，会导致后续CHANGE REPLICATION SOURCE TO失败 -
binlog相关配置（如log_bin、binlog_format）不会复制，需提前在 recipient 的my.cnf中配好 -
SHOW SLAVE STATUS必为空，必须手动执行CHANGE REPLICATION SOURCE TO SOURCE_HOST='x.x.x.x', SOURCE_USER='repl', SOURCE_PASSWORD='xxx'
最易被忽略的是：克隆后 auto.cnf 里的 server_uuid 和 donor 完全一致，不删就启，START REPLICA 会直接拒绝连接——这不是权限或网络问题，是 UUID 冲突本身。
