这是《MySQL 8.0 源码与内核实战》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 Clone Plugin 用于物理克隆本地或远程实例数据，是快速搭建从库和 MGR 成员的常用方式。
28.1 方式
| 类型 | 说明 |
|---|---|
| local clone | 从本实例克隆到目录 |
| remote cloning | 从 donor 克隆到 recipient |
远程克隆会替换 recipient 数据，执行前必须确认目标实例可销毁。
28.2 使用
安装插件：
INSTALL PLUGIN clone SONAME 'mysql_clone.so';
本地：
CLONE LOCAL DATA DIRECTORY='/backup/clone-20260825';
远程：
SET GLOBAL clone_valid_donor_list='10.0.0.11:3306';
CLONE INSTANCE FROM 'clone_user'@'10.0.0.12':3306
IDENTIFIED BY 'password';
28.3 克隆内容
物理克隆包含数据目录相关状态：
- InnoDB 数据；
- redo；
- undo；
- 数据字典；
- 配置相关状态；
- 复制位点或 GTID 信息。
克隆后通常要调整 server_uuid、复制配置和实例参数。
28.4 过程
recipient connect donor
-> check version and compatibility
-> snapshot transfer
-> apply files
-> recover
-> restart recipient
可通过 performance_schema 观察阶段。
28.5 权限
donor 用户需要 BACKUP_ADMIN，recipient 需要 CLONE_ADMIN。网络账号、SSL 和 clone_valid_donor_list 要按环境配置。
28.6 与备份恢复对比
| 方案 | 特点 |
|---|---|
| Clone | 物理快照，速度快，适合建从库 |
| XtraBackup | 物理备份，备份集管理更灵活 |
| mysqldump | 逻辑导出，速度慢但兼容性高 |
| snapshot | 依赖存储一致性 |
Clone 不是长期保留多个时间点的备份策略。
28.7 注意事项
- 目标数据会被覆盖；
- 版本和平台兼容性要确认；
- 磁盘空间必须充足；
- 克隆期间 donor 有 IO 压力；
- 大实例会占用网络；
- 加密和压缩配置要匹配；
- 完成后验证 GTID 和数据校验。
本章小结
Clone Plugin 提供物理克隆能力，适合快速重建从库和 MGR 成员。它的核心优势是速度和一致性，但不能替代完整备份策略。
思考题
- local clone 和 remote clone 的区别是什么？
- 克隆后为什么可能要调整 server_uuid？
- Clone 与 XtraBackup 的适用场景有什么不同？
- donor 和 recipient 各需要什么权限？
- 为什么 Clone 不能替代多时间点备份？