performance_schema.clone_status 不反映实时进度，因其仅在克隆各阶段（init→file copy→page copy→redo copy→done）切换完成时写入快照，中间过程无更新；state为“in progress”不表示卡死，而是阶段未结束，需结合show processlist、错误日志、i/o及目录大小变化交叉验证。
CLONE INSTANCE 不是同步，它不提供实时进度反馈——执行过程是阻塞的，期间只能查状态表，不能“监控同步中”的流式指标。
为什么 performance_schema.clone_status 看不到实时进度？
clone_status 表只记录**已完成阶段**的状态快照，不是持续更新的进度条。克隆分 5 个内部阶段（INIT → FILE COPY → PAGE COPY → REDO COPY → DONE），但表里只在阶段切换完成时才写入新行，中间过程无可见变化。
常见现象：执行 CLONE INSTANCE FROM 'user@donor:3306' 后，SELECT * FROM performance_schema.clone_status 返回空或长时间卡在 STATE = "In Progress"，这不是卡死，而是阶段尚未结束、尚未落库。
- 该表设计目的不是供人“盯屏看进度”，而是供脚本判断是否完成或失败
- 没有
percent_complete或bytes_transferred字段，MySQL 官方未暴露底层传输粒度 - 远程克隆实际走的是 MySQL 自有协议 + 压缩流，不经过 binlog 或网络监控层，无法用
netstat或tcpdump准确估算剩余时间
真正能反映“还在干活”的信号有哪些？
别依赖单一张表，要交叉验证几个低层信号：
- 查
SHOW PROCESSLIST：执行克隆的连接状态必须是State: Clone operation，且Command为Query（不是Sleep） - 看 recipient 的错误日志：
tail -f /var/log/mysql/error.log，会有类似Clone Donor: file copy completed、Page copy started的阶段性提示 - 观察 donor 和 recipient 的磁盘 I/O：
iostat -x 1，%util或await明显升高说明正在读/写文件或页 - 检查 recipient 数据目录大小变化：
du -sh /var/lib/mysql，如果大小在缓慢增长，说明还没卡住（注意：PAGE COPY 阶段增长可能暂停几秒）
clone_status 表字段该怎么读？
这张表只有 5 列，关键就看三列：
-
STATE：只取值Not Started/In Progress/Completed/Failed—— “In Progress” 持续 10 分钟不等于失败，可能是大实例在做 PAGE COPY -
END_TIME：为空表示没结束；非空且STATE = Completed才算成功落地 -
ERROR_NO：非 0 才代表出错，比如1126（插件未加载）、3095（权限不足）、3857（磁盘空间不足）——但很多静默失败（如网络中断）不会立刻填这个字段，得结合 error log
别用 WHERE STATE = 'In Progress' 轮询等结果，它不保证活跃性；更可靠的做法是：SELECT COUNT(*) FROM performance_schema.clone_status WHERE STATE = 'Completed'，轮询直到返回 1。
容易被忽略的“假完成”陷阱
克隆命令返回成功 ≠ 实例已可用。recipient 会自动重启，但重启后可能因配置冲突直接 crash：
-
auto.cnf没删：启动时报Server ID conflict或UUID mismatch -
server_id未改：和 donor 冲突，后续配主从时CHANGE REPLICATION SOURCE TO报错 -
gtid_executed被原样复制，但 recipient 的gtid_purged没对齐，导致START REPLICA失败
所以真正的“完成”检查点，是 recipient 重启后能连上、SELECT @@server_uuid 和 donor 不同、且 SHOW REPLICA STATUS\G 不报错——这些都得手动确认，克隆本身不帮你做。
