clone instance 是物理快照拷贝而非同步，执行后目标实例自动重启停机5–15秒，无持续复制能力；需插件永久加载、两端权限分离、清理auto.cnf并校准server_uuid，否则易引发启动失败或主从冲突。
CLONE INSTANCE 不是同步，是物理快照拷贝——执行完目标实例自动重启停机 5–15 秒，没有持续复制能力。它适合快速建从库或灾备重建，但不能替代主从复制或 GTID 同步。
插件必须 ACTIVE 且永久加载，否则命令直接报错
很多报错如 ERROR 1126 (HY000): Can't open shared library 'mysql_clone.so' 或 Unknown command 'CLONE'，根本原因不是权限或网络，而是插件压根没加载成功。
- 先查状态：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'clone';，结果必须是ACTIVE -
INSTALL PLUGIN clone SONAME 'mysql_clone.so';（Linux）只在当前会话有效，MySQL 重启后失效 - 永久生效必须改
my.cnf：[mysqld] plugin-load-add = mysql_clone.so clone = FORCE_PLUS_PERMANENT
，然后systemctl restart mysqld（reload不起作用） - 注意文件名：Linux 是
mysql_clone.so，Windows 是mysql_clone.dll
远程克隆必须 donor 和 recipient 各配权限、各设白名单
权限不是“一个账号通吃两端”，CLONE INSTANCE 是 recipient 主动拉取 donor 数据，角色严格分离。
- donor 端用户（如
'clone_donor'@'192.168.10.5'）需BACKUP_ADMIN（必需），加REPLICATION SLAVE方便后续配主从 - recipient 端用户（如
'clone_recip'@'localhost'）必须有CLONE_ADMIN（隐含SHUTDOWN，因克隆完要自动重启） - recipient 上必须执行：
SET GLOBAL clone_valid_donor_list = '192.168.10.5:3306';（不能带http://，IPv6 地址不支持） - donor 的
bind_address不能是127.0.0.1，得设成0.0.0.0或具体内网 IP，并放行防火墙/云安全组的 3306 端口
克隆完成后必须手动清理 auto.cnf 并校准 server_uuid
克隆是物理拷贝，auto.cnf、server_uuid、gtid_executed 全部原样复制——不处理，新实例启动失败或主从直接冲突。
- recipient 重启后第一件事：
rm -f /var/lib/mysql/auto.cnf，让 MySQL 重启时重生成server_uuid - 检查
SELECT @@server_uuid;，确认和 donor 不同；若相同，说明auto.cnf没删干净 - 手动更新
my.cnf：确保server_id唯一、gtid_mode=ON、log_bin开启（如果要做主从） - 别指望克隆自动恢复配置——
CLONE INSTANCE只覆盖数据目录，不碰配置文件
本地克隆前目标路径必须为空且属主正确
克隆不是复制文件到已有目录，而是覆盖式重建整个数据目录结构。
- 目标路径必须不存在，例如用
/data/clone_20260702而非/data/mysql - 创建后立即执行：
chown -R mysql:mysql /data/clone_20260702，否则报错类似Cannot create directory: Permission denied -
innodb_file_per_table=OFF的旧实例无法被克隆；recipient 若仍启用该模式，会触发Invalid tablespace file - 克隆期间 donor 上任何 DDL 操作都会阻塞克隆，建议避开业务高峰
server_uuid 冲突、auto.cnf 残留、权限跨端复用、插件未永久加载——这四点，占了线上故障的九成以上。动手前先跑一遍 SELECT PLUGIN_NAME, PLUGIN_STATUS ...，比什么都管用。
