CLONE INSTANCE 是原子级物理快照，非逻辑同步；静默卡住或报 ERROR 3864 是因插件未加载、clone_valid_donor_list 未设、donor bind_address 为 127.0.0.1、端口未放行或权限不足所致。
CLONE INSTANCE 不是复制 SQL，也不是重放 binlog，而是直接拷贝 InnoDB 物理文件（ibdata1、ib_logfile*、表空间、redo 日志）、数据字典元数据和 GTID_EXECUTED 快照值，生成一个可立即启动的完整数据目录。它本质是原子级物理快照，不是逻辑同步。
为什么 CLONE INSTANCE 会静默卡住或报 ERROR 3864
这不是网络连通性问题本身，而是 donor 和 recipient 双向校验失败后主动中止的表现：
- SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'clone' 在任一端返回空或 DISABLED——插件未真正加载
- recipient 未执行 SET GLOBAL clone_valid_donor_list = '192.168.0.101:3306'（注意不能带 http://，不能用 127.0.0.1）
- donor 的 bind_address 是 127.0.0.1，导致 recipient 无法建立 TCP 连接
- 防火墙/SELinux/云安全组未放行 donor 的 3306 端口（注意：不是 recipient 的端口）
- donor 端用户缺少 BACKUP_ADMIN 或 REPLICATION SLAVE；recipient 端用户没给 CLONE_ADMIN，或账号 host 不匹配（如用了 'root'@'%'）
CLONE LOCAL DATA DIRECTORY 和 CLONE INSTANCE FROM 权限差异
两者走完全不同的权限路径，不能混用账号或复用权限：
- CLONE LOCAL DATA DIRECTORY 只需当前登录用户拥有 BACKUP_ADMIN；目标路径必须不存在，且 mysqld 进程属主（通常是 mysql:mysql）对该路径有写权限
- CLONE INSTANCE FROM 要求：
- donor 端用户（如 'clone_donor'@'192.168.0.101'）必须有 BACKUP_ADMIN + REPLICATION SLAVE
- recipient 端用户（如 'clone_recip'@'localhost'）必须有 CLONE_ADMIN（该权限隐含 SHUTDOWN，克隆后会自动重启）
- recipient 上的 CLONE_ADMIN 用户不能是 donor 端的同名账号，也不能是宽泛账号——必须显式创建并限定 host
克隆完成后为什么不能直接配主从
因为 CLONE 只复制了数据文件和 GTID_EXECUTED 值，不写 master.info、不设置 source_host、不启动 IO_THREAD / SQL_THREAD，更不会继承 donor 的 server_id 或 binlog_format 配置：
- recipient 克隆后自动重启，但 my.cnf 中的 server_id 若未提前设好，会导致后续 CHANGE REPLICATION SOURCE TO 失败
- 必须手动执行 rm -f /var/lib/mysql/auto.cnf（Linux 路径），否则 server_uuid 冲突，START REPLICA 直接拒绝连接
- recipient 的 my.cnf 必须提前启用 log_bin、设好 gtid_mode = ON、确认 innodb_file_per_table = ON
auto.cnf 不删、server_uuid 不更新、binlog 不开——这三件事不做，克隆完的实例就只是个“数据快照”，不是可用的从库。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
