必须版本完全一致，8.0.39 donor 克隆到 8.0.38 recipient 会报 ER_CLONE_DONOR_VERSION_MISMATCH 错误；Docker 中需用 --pull=always 并锁定补丁号（如 mysql:8.0.39），执行 SELECT VERSION() 和 mysqld --version 双重验证。
克隆前必须确认 donor 和 recipient 版本完全一致
MySQL CLONE 插件对版本极其敏感：8.0.39 donor 克隆到 8.0.38 recipient 会报错 ER_CLONE_DONOR_VERSION_MISMATCH，哪怕只是小版本差一位。这不是警告，是硬性失败。Docker 场景下尤其容易踩坑——你以为用的是 mysql:8.0.39 镜像，但 base image 可能被缓存或未强制 pull。实操建议：
• 在 donor 和 recipient 上都执行 SELECT VERSION(); 和 SELECT @@GLOBAL.plugin_dir; 对照
• 使用 mysqld --version 检查二进制实际版本
• Docker 中务必加 --pull=always 启动容器
• 不要依赖 mysql:8.0 这类 tag，必须锁定补丁号（如 mysql:8.0.39）
远程克隆时 recipient 必须提前清空 datadir 并关闭 mysqld
远程克隆（CLONE FROM 'user@donor_host:3306'）默认行为是直接覆盖 datadir 目录内容，但前提是目标 mysqld 已停止。如果 mysqld 正在运行，克隆命令会卡住或报错 ER_CLONE_IN_PROGRESS。常见错误现象是命令无响应、CPU 占用高、日志里反复出现 Waiting for donor to send data。正确流程：
• 执行 systemctl stop mysqld 或 kill -15 $(cat /var/run/mysqld/mysqld.pid)
• 确认进程已退出：ps aux | grep mysqld
• 删除或重命名原 datadir（如 /var/lib/mysql → /var/lib/mysql.bak），避免残留 pid 文件或 socket
• 再启动 mysqld，执行克隆命令
• 克隆完成后，datadir 会被完整替换，无需手动解压或导入
压力测试前必须重置 server_id 和禁用 binlog
克隆生成的实例继承 donor 的 server_id 和 binlog 设置，这会导致 sysbench 压测时与生产库冲突（比如主从复制误触发、GTID 冲突）。即使你只用它做单机压测，重复的 server_id 也可能让监控系统误判为集群节点。实操关键点：
• 克隆完成后，启动 mysqld 前修改配置文件：server_id = 201（确保唯一）、skip_log_bin（禁用 binlog，减少写放大）
• 若使用 Docker，可在启动命令中注入：--server-id=201 --skip-log-bin
• 不要依赖克隆后动态改 SET GLOBAL —— server_id 是只读变量，必须重启生效
• 检查是否生效：SELECT @@server_id, @@log_bin; 返回 201 和 OFF 才算成功
本地克隆更适合 CI/CD 流水线中的快速环境准备
如果你在 Jenkins/GitLab CI 中跑 sysbench，远程克隆网络开销大、超时风险高；本地克隆（CLONE LOCAL DATA DIRECTORY = '/tmp/test_env'）更可靠。但它要求 donor 实例在同一台机器上，且磁盘空间足够存放两份数据。注意：
• CLONE LOCAL 不需要网络权限，也不依赖 donor 的 BACKUP_ADMIN，只要执行用户有 CLONE_ADMIN
• 克隆出的目录可直接用于启动新实例：mysqld --datadir=/tmp/test_env --port=3307 --socket=/tmp/mysql-test.sock
• 避免用 /tmp 存放大量数据（可能被系统清理），推荐挂载独立卷或使用 /var/lib/mysql-clone
• 如果流水线并发执行多个压测任务，每个任务必须用不同 datadir 和 port，否则端口或文件锁冲突
SELECT VERSION() 和 ps aux | grep mysqld 这两步——90% 的失败都卡在这儿。 
