MySQL 克隆副本后怎样取得随数据转移的复制坐标

MySQL Clone Plugin 完成副本初始化后，复制坐标不是靠猜，也不是去 donor 上重新执行一次 SHOW BINARY LOG STATUS。克隆过程会把 donor 当时的二进制日志文件位点和 gtid_executed 集合传给 recipient；但 binlog、relay log 这些日志文件本身不会随数据一起复制。最直接的做法，是在克隆后的 recipient 上读取这两类信息，再按现有复制拓扑选择 GTID 或文件位点方式接入。

官方资料入口：https://dev.mysql.com/doc/refman/8.4/en/clone-plugin-replication.html

先区分“坐标已传递”和“日志文件已复制”

这次变化的关键不是 Clone Plugin 替你完成了整条复制链路，而是它把数据快照对应的复制位置一起交给了 recipient。对于 GTID 复制，这个集合可以让新副本使用自动定位；对于文件位点复制，则需要把文件名和偏移填入复制通道。

因此，克隆成功后不要把 recipient 上已有的 relay log 当成 donor 的日志副本，也不要把克隆时间当成位点。真正可用的坐标必须来自克隆产生的状态记录或系统变量。

文件位点复制：从 clone_status 取坐标

在 recipient 上执行下面的查询。结果中的文件名和偏移，就是克隆时从 donor 传过来的二进制日志坐标。

-- 查询克隆操作传递到 recipient 的文件位点
SELECT BINLOG_FILE, BINLOG_POSITION
FROM performance_schema.clone_status;

把返回值代入复制通道配置时，保留源端地址、端口和认证参数，只替换为这两个坐标：

-- 使用克隆坐标创建文件位点复制通道
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = 'source.example.internal',
  SOURCE_PORT = 3306,
  SOURCE_LOG_FILE = 'binlog.000127',
  SOURCE_LOG_POS = 845921,
  FOR CHANNEL 'clone_channel';

-- 启动指定通道；生产环境应使用专用复制账号
START REPLICA FOR CHANNEL 'clone_channel';

如果是 MySQL 8.4 的新配置语法，也可以使用文档中的 CHANGE SOURCE TO 形式。多线程副本的 relay log recovery 通常不能完全自动完成，遇到恢复错误时应按通道重新配置，不要盲目重复启动。

GTID 复制：直接读取 gtid_executed

如果拓扑采用 GTID，通常不需要手工拼接日志文件和偏移。先在 recipient 上保存克隆后的 GTID 集：

-- 查看克隆传递并应用到 recipient 的 GTID 集合
SELECT @@GLOBAL.GTID_EXECUTED AS cloned_gtid_set;

之后为通道开启自动定位。这里的重点是 SOURCE_AUTO_POSITION = 1：启动复制时，recipient 会依据自己已执行的 GTID 与 source 协商缺少的事务。

-- 让 GTID 自动定位决定需要追赶的事务
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = 'source.example.internal',
  SOURCE_PORT = 3306,
  SOURCE_AUTO_POSITION = 1,
  FOR CHANNEL 'clone_channel';

-- 启动 GTID 通道并继续追赶 source
START REPLICA FOR CHANNEL 'clone_channel';

这条路径适合 donor 已经处于 GTID 拓扑、recipient 也配置为兼容 GTID 模式的场景。若 recipient 是从拓扑中的 replica 克隆而来，原有使用 GTID 自动定位的通道有机会在启动后自动恢复；若改用新通道或不同 source，仍要显式执行通道配置。

上线前的三个边界检查

实际操作中，我会先把两个查询结果写入变更记录，再立即配置通道并观察复制线程状态。Clone Plugin 解决的是“大数据量初始传输”的效率问题，不会替你延长 source 的日志保留期；克隆完成与启动复制之间拖得越久，恢复窗口越窄。

常见问题

克隆后为什么找不到 donor 的 binlog 文件？

这是正常边界。克隆传递的是复制坐标，不是 donor 的 binlog 和 relay log 文件；新副本需要从 source 重新拉取仍保留的日志。

已经有 GTID 了，还要读取 BINLOG_POSITION 吗？

GTID 自动定位场景通常不需要。读取文件位点主要用于传统文件位点复制、排障记录或需要与旧拓扑对齐的场景。