如何在MySQL 8.0中通过Clone插件快速同步副本数据？

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.soclone = 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 ...，比什么都管用。