MySQL Clone Plugin 自 MySQL 8.0.17 起提供真正在线物理克隆能力，通过直接拷贝 InnoDB 数据文件、redo 日志及 GTID 位点实现秒级主从搭建，但需严格满足插件激活（ACTIVE）、权限分治（donor 用 BACKUP_ADMIN+REPLICATION SLAVE，recipient 用 CLONE_ADMIN）、配置对齐（innodb_file_per_table=ON、innodb_log_file_size 一致）、网络与磁盘资源充足等条件，否则易卡住或静默失败。
CLONE 插件在 MySQL 8.0.17+ 中是真正可用的在线克隆方案，不是“复制 SQL”或“重放 binlog”，而是直接拷贝物理文件 + redo 日志 + GTID 位点，克隆完就能立刻配主从。但实际用错一步，CLONE INSTANCE 就会卡住、报错、甚至静默失败。
确认插件已安装且状态为 ACTIVE
别跳过这步——很多失败源于插件没真正激活。
- 运行
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'clone';，结果必须是ACTIVE；若为DISABLED或空，说明未加载 - 动态安装用：
INSTALL PLUGIN clone SONAME 'mysql_clone.so';（Linux）或INSTALL PLUGIN clone SONAME 'mysql_clone.dll';（Windows） - 永久生效建议写进
my.cnf：[mysqld] plugin-load-add=mysql_clone.so clone=FORCE_PLUS_PERMANENT
，然后重启 mysqld - 注意：仅执行
INSTALL PLUGIN不等于插件就“随时可用”，它依赖innodb_file_per_table=ON（目标实例必须开启），否则克隆中途报Invalid tablespace file
远程克隆必须配对设置 donor 和 recipient 权限
权限不是“给一个用户就行”，而是 donor（源）和 recipient（目标）各需不同权限，且账号必须在两端都存在。
- donor 端用户（如
'clone_user'@'192.168.0.101'）必须有：BACKUP_ADMIN（必需）、REPLICATION SLAVE（后续配主从用） - recipient 端用户（如
'clone_user'@'192.168.0.102'）必须有：CLONE_ADMIN（隐含BACKUP_ADMIN+SHUTDOWN），否则执行CLONE INSTANCE时提示ERROR 3095 (HY000): Insufficient privileges - recipient 上还需提前设好白名单：
SET GLOBAL clone_valid_donor_list = '192.168.0.101:3306';，否则连不上 donor - donor 的
bind_address不能是127.0.0.1，得设为0.0.0.0或具体内网 IP，并确保防火墙放行 3306
CLONE INSTANCE 执行后自动重启，但配置不会自动恢复
这是最容易被忽略的“断点”：克隆完成后 recipient mysqld 会主动退出，靠 systemd 或 mysqld_safe 拉起新进程，但原 my.cnf 里的 server_id、gtid_mode、log_bin 等配置还在，而数据已是 donor 的快照——不手动重配，启动后无法做主从。
- 克隆命令示例：
CLONE INSTANCE FROM 'clone_user'@'192.168.0.101':3306 IDENTIFIED BY 'Rsdkyt#2024!'; - 执行后查进度：
SELECT stage, state, begin_time, end_time FROM performance_schema.clone_progress;，state = 'Completed'才算成功 - 重启后第一件事：登录，检查
SELECT @@server_id;是否仍是 donor 的值（比如80203318）；若是，立刻改my.cnf并重启，或在线改（SET PERSIST server_id = 80203319;） - 接着配主从：
CHANGE MASTER TO MASTER_HOST='192.168.0.101', MASTER_PORT=3306, MASTER_USER='repl', MASTER_PASSWORD='...', MASTER_AUTO_POSITION=1;，再START SLAVE;
磁盘空间和参数一致性是静默失败的主因
日志里只显示泛化错误如 ERROR 3880 (HY000): Clone Donor Error，但真实原因往往藏在资源层。
- recipient 磁盘剩余空间必须 ≥ donor 当前
datadir占用空间 × 2：一份用于克隆中临时写入，一份用于最终替换后的数据目录 - 两端
innodb_log_file_size必须一致，否则克隆后启动报InnoDB: Invalid log file size，只能删掉ib_logfile*重建（丢失未刷盘事务） -
clone_ddl_timeout默认 300 秒，若克隆期间 donor 有长事务或 DDL 正在执行，克隆会直接失败；可临时调大，但更稳妥的是克隆前停业务或等 DDL 完成 - 别用
CLONE LOCAL DIRECTORY替代CLONE INSTANCE做跨机同步——它只写本地路径，不走网络传输，误用会导致“命令执行成功但目标库完全没变”
my.cnf 里一行参数、防火墙一条规则、磁盘上少留 5GB 空间。 
