mysql clone插件需源（donor）和目标（recipient）两端均启用，且版本需≥8.0.27才支持远程克隆；克隆期间donor阻塞ddl但不影响dml，recipient无需停写；克隆后须手动校准server_uuid、gtid_executed和auto_increment值。
Clone插件必须在源和目标实例都启用
MySQL Clone 插件不是“一端装就能用”的工具，它要求 source 和 donor（即被克隆方）以及 recipient（即接收方）两端都加载并激活插件。常见错误是只在 donor 上执行 INSTALL PLUGIN clone SONAME 'mysql_clone.so'，结果 recipient 执行 CLONE INSTANCE 时直接报错 ERROR 3863 (HY000): Clone not supported。
实操建议：
- 两边都要检查：运行
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'clone'，确认状态都是ACTIVE - 配置文件中需显式启用：在
my.cnf的[mysqld]段落添加plugin_load_add = mysql_clone.so，避免重启后失效 - 注意版本对齐：Clone 插件从 MySQL 8.0.17 引入，但 8.0.27+ 才支持远程克隆（即跨实例），低于该版本只能本地克隆（
CLONE LOCAL DATA DIRECTORY）
远程克隆必须走专用端口且网络策略要放开
Clone 插件默认使用 donor 实例的主端口（如 3306）传输数据，但实际会额外建立一个独立连接通道，由 clone_block_ddl 和后台线程控制。如果你看到 ERROR 3864 (HY000): Clone Donor connection failed 或连接超时，大概率是防火墙或安全组没放行 donor 的端口——哪怕你只打算从 recipient 连 donor 的 3306，Clone 内部仍可能尝试其他端口协商（尤其在高并发 clone 时）。
实操建议：
- 强制指定 donor 端口：在 recipient 上执行前，先设置
SET GLOBAL clone_valid_donor_list = 'donor_host:3306'，确保只连这个地址和端口 - 关闭 donor 的 SELinux 或 AppArmor（若启用），否则可能拦截 socket 创建，表现为
errno 13类权限错误 - 不要复用复制用户：Clone 不走 SQL 层，不需要
REPLICATION SLAVE权限，但需要BACKUP_ADMIN+CLONE_ADMIN；用普通账号会直接拒绝
克隆过程会阻塞 donor 上所有 DDL，但不影响 DML
Clone 是物理层拷贝，为保证一致性，它会在 donor 上全局加一个轻量级排他锁（clone_block_ddl），导致所有 CREATE/DROP/ALTER 类语句被挂起，直到 clone 完成或失败。这不是 bug，是设计使然——DDL 可能重写表空间、移动 ibd 文件，与正在读取的物理页冲突。
实操建议：
- 避开业务高峰执行 clone，尤其注意定时任务里的
OPTIMIZE TABLE或分区维护操作 - 监控 donor 状态：查
SHOW PROCESSLIST，如果看到大量Waiting for clone lock，说明已有 DDL 被卡住，此时再发起 clone 会进一步加剧阻塞 - recipient 不需要停写：它全程处于初始化状态，克隆完成前不接受任何连接；但 donor 的
INSERT/UPDATE/SELECT全部照常
克隆后 recipient 的 auto-increment 和 GTID 需手动对齐
Clone 插件会完整复制数据文件、系统表、binlog 位置，但不会自动同步 recipient 的 auto_increment_offset、server_uuid 或 gtid_executed。如果你后续想把 recipient 接入主从或 MGR，直接启动复制会因 UUID 冲突或 GTID 跳变失败。
实操建议：
- 克隆完成后立刻登录 recipient，执行
SELECT @@server_uuid，若和 donor 相同，必须改掉：SET PERSIST server_uuid = 'xxx'（然后重启 mysqld） - 检查
SELECT @@gtid_executed是否与 donor 一致；如果不一致（比如 recipient 原有旧数据），需手动SET GTID_NEXT+ 空事务补全，或清空mysql.gtid_executed表（仅当确认无残留事务时） -
auto_increment值不会继承 donor 当前最大值——InnoDB 表的 AI 值只存于内存，克隆后 recipient 会从表定义里读初始值；如有自增列，建议克隆后对每张表执行SELECT MAX(id) FROM t并调大auto_increment_offset
物理拷贝快是快，但克隆完不是“开箱即用”。server_uuid、GTID、auto_increment 这三样，漏掉任何一个，后续接入高可用架构时都会卡在第一关。
