MySQL Clone 插件怎么为副本准备一致数据

给已有数据的 MySQL 副本做初始化时，Clone 插件的价值不是“把 SQL 再执行一遍”，而是把 donor 的 InnoDB 物理快照、数据字典和复制坐标交给 recipient。这样副本先落在一个一致位置，再从这个位置继续追二进制日志。它适合大数据量的同系列实例，但默认会清理接收端已有的用户数据与二进制日志，并在克隆完成后重启 MySQL，所以不能把一台正在承载独立数据的实例直接当接收端。

官方文档：https://dev.mysql.com/doc/refman/8.4/en/clone-plugin.html

先把这个小项目的边界定清楚

这里的目标是用一台已有数据的 MySQL 8.4 donor 初始化一台新的 MySQL 8.4 recipient，然后把 recipient 接到同一复制源。两端启用 GTID，recipient 的现有数据允许被覆盖。若是多源复制、跨 8.0 与 8.4 系列、包含必须保留的非 InnoDB 数据，应该换用更合适的数据准备方法。

我第一次把 Clone 当成“更快的备份恢复”时，最容易忽略的就是接收端边界：不指定 DATA DIRECTORY 时，远程克隆会移除接收端用户创建的数据、表空间和二进制日志，再写入 donor 数据并触发重启。这个动作更接近实例置换，而不是把若干表追加进去。

环境准备要同时看兼容、权限与存储

正式执行前，我会先核对两端的版本系列、操作系统和平台、服务器字符集与排序规则、innodb_page_size、innodb_data_file_path、活动插件以及接收端磁盘空间。加密数据还要求安全连接和匹配的文件系统条件；两端 max_allowed_packet 不能低于 2MB。

插件需要在两端启用。下面的示例把 donor 传输权限和 recipient 执行权限分开，生产环境还应按实际主机限制账号来源：

-- donor：安装 Clone 插件并创建只负责提供快照的账号
INSTALL PLUGIN clone SONAME 'mysql_clone.so';
CREATE USER 'clone_donor'@'recipient.example.com' IDENTIFIED BY '替换为强密码';
GRANT BACKUP_ADMIN ON *.* TO 'clone_donor'@'recipient.example.com';

-- recipient：安装插件；当前操作账号需要替换数据并重启实例的权限
INSTALL PLUGIN clone SONAME 'mysql_clone.so';
GRANT CLONE_ADMIN ON *.* TO 'clone_operator'@'localhost';

在接收端发起克隆并预留重启窗口

先把 donor 的经典 SQL 端口加入 recipient 的允许列表，再由具备 CLONE_ADMIN 的接收端会话执行 CLONE INSTANCE。这里使用的是 3306，不是 X Protocol 端口，也不经 MySQL Router。

-- recipient：只允许从指定 donor 地址取得克隆数据
SET GLOBAL clone_valid_donor_list = 'donor.example.com:3306';

-- recipient：发起远程克隆；该语句会使用 donor 账号读取物理快照
CLONE INSTANCE FROM 'clone_donor'@'donor.example.com':3306
IDENTIFIED BY '替换为强密码'
REQUIRE SSL;

默认数据目录模式下，写入完成后 MySQL 会尝试自动重启。recipient 必须由能够监测并拉起 mysqld 的监督进程管理；如果出现 ERROR 3707，它表示自动重启失败，不等同于数据克隆失败。此时应手动启动服务，再查询克隆状态，而不是立刻重新覆盖一次。

克隆完成后确认一致位置

Clone 为复制场景准备的关键不是复制二进制日志文件，而是提取 donor 的二进制日志文件名、位置与 gtid_executed，并传给 recipient。复制元数据表也会随数据目录复制，但接收端自己的服务器配置仍保留。因此，重启后要同时看克隆状态和 GTID，而不能只确认 mysqld 已启动。

-- recipient：确认克隆状态携带的文件位置
SELECT STATE, BINLOG_FILE, BINLOG_POSITION
FROM performance_schema.clone_status;

-- recipient：GTID 模式下确认 donor 的已执行事务集合已经应用
SELECT @@GLOBAL.GTID_EXECUTED;

让副本从克隆点继续追平

如果 donor 本身就是拓扑中的副本，并且原通道使用 GTID 自动定位，复制元数据可能允许 recipient 在启动对应通道后继续工作；但我更倾向于明确检查通道指向，避免把 donor 的连接配置不加判断地带到新节点。对于从 source 克隆后新建的 GTID 副本，可显式配置来源：

-- recipient：使用专门的复制账号，并依靠 GTID 自动定位缺失事务
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = 'source.example.com',
  SOURCE_PORT = 3306,
  SOURCE_USER = 'repl_user',
  SOURCE_PASSWORD = '替换为复制密码',
  SOURCE_AUTO_POSITION = 1;

-- recipient：启动通道后再检查接收线程、应用线程和延迟
START REPLICA;
SHOW REPLICA STATUS;

克隆完成到启动复制之间不要拖太久，因为 recipient 追平所需的二进制日志必须仍保留在 source 上。若这些日志已被清理，复制握手会失败，只能重新准备可用起点。完成后至少确认复制 I/O 与 SQL 线程状态、GTID 是否继续增长，以及业务抽样数据是否符合预期。

什么时候不该用 Clone

Clone 会复制 binary log 吗？

不会复制二进制日志文件，但会传递用于复制衔接的文件位置与 GTID 集合。

克隆时 donor 还能写入吗？

Clone 会取得一致物理快照，并在必要阶段协调 DDL；业务写入边界仍应结合版本、并发 DDL 和容量评估安排窗口。

为什么克隆成功后还要检查复制通道？

一致数据只解决起点，后续还依赖来源地址、账号、GTID 模式、日志保留和通道状态。把这几项一起验收，副本才算真正可用。