“秒级恢复”是误导性说法——TB级数据用Clone Plugin不可能秒级完成，实际耗时数分钟至数十分钟，取决于磁盘I/O、网络带宽和clone_buffer_size配置；真正秒级完成的仅限GB级（如2–5 GB）实例。
“秒级恢复”是误导性说法——TB级数据用Clone Plugin不可能秒级完成，实际耗时在数分钟到数十分钟，取决于磁盘I/O、网络带宽和clone_buffer_size配置。真正能秒级完成的，只有GB级（如2–5 GB）实例。别被宣传话术带偏，先看清物理限制再动手。
确认 clone 插件已永久启用且状态为 ACTIVE
90% 的失败卡在这一步：插件看似装了，实则没加载或重启后失效。动态执行 INSTALL PLUGIN clone SONAME 'mysql_clone.so' 只是临时生效，MySQL 重启即丢失。
- 必须在
my.cnf的[mysqld]段添加两行：plugin-load-add = mysql_clone.so和clone = FORCE_PLUS_PERMANENT - Linux 下文件名是
mysql_clone.so，Windows 是mysql_clone.dll，写错直接报ERROR 1126 (HY000): Can't open shared library 'mysql_clone.so' - 改完配置必须
systemctl restart mysqld；reload不触发插件重载 - 登录后立刻验证：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'clone'，结果必须是ACTIVE
远程克隆前 donor/recipient 双向权限与白名单缺一不可
远程克隆不是 recipient 单方面发起就能连上的操作。漏掉任意一端的任一条件，都会静默卡住或报 ERROR 3864 (HY000): Clone Donor connection failed 或 ERROR 3095 (HY000): Insufficient privileges。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- donor 端用户（如
'cloner'@'192.168.0.101'）需同时具备：BACKUP_ADMIN（必需）、REPLICATION SLAVE（后续配主从用） - recipient 端用户（如
'cloner'@'localhost'）必须有CLONE_ADMIN（该权限隐含BACKUP_ADMIN+SHUTDOWN），不能复用复制账号或只给BACKUP_ADMIN - recipient 必须提前执行：
SET GLOBAL clone_valid_donor_list = '192.168.0.101:3306'（地址必须精确到 IP+端口，不能带http或域名） - 两端用户账号需真实存在、密码一致（远程克隆会校验凭据），若启用 SSL，还需双方
require_secure_transport=ON时同步配置REQUIRE SSL
本地克隆失败几乎全是目录权限或空间问题
CLONE LOCAL DATA DIRECTORY 不是“复制到已有目录”，而是清空目标路径、重建整个数据目录结构。哪怕路径下只有一行 .keep 文件，也会失败。
- 目标路径必须**不存在**：
/data/clone_20261013✅，/data/mysql❌，/data/clone_20261013/（末尾斜杠不关键，但路径不能已存在）❌ - 创建后立即执行：
chown -R mysql:mysql /data/clone_20261013——只改父目录属主不够，子目录和文件也要递归归属 - 磁盘剩余空间必须 ≥ 当前
datadir实际占用（用du -sh /var/lib/mysql看），CLONE不压缩、不去重 - 大库（>50 GB）克隆慢？可调大
clone_buffer_size（默认 4 MB），加到my.cnf：clone_buffer_size = 32M，仅对本地克隆生效
克隆后 server-uuid 保留但 server-id 不变，主从配置必须手动补全
克隆完成后，recipient 实例会自动重启，数据目录被完全覆盖，但 auto.cnf 中的 server-uuid 被保留——这是设计行为，也是关键点。若忽略，后续启动复制会因 UUID 冲突拒绝连接 donor。
- 克隆结束、recipient 自动重启后，立刻执行：
CHANGE REPLICATION SOURCE TO SOURCE_HOST='192.168.0.101', SOURCE_USER='repl', SOURCE_PASSWORD='xxx', SOURCE_AUTO_POSITION=1 -
server-id需人工修改（否则与 donor 冲突），在my.cnf中设新值并重启，或运行SET PERSIST server_id = 102（MySQL 8.0.23+） - 克隆过程不拷贝 binlog，所以
SOURCE_AUTO_POSITION=1能用的前提是 donor 已开启 GTID 且未清理所需 binlog - 首次克隆后若需增量同步，不能依赖 Clone 自身——它不提供增量机制，得靠传统 binlog 复制续上
最易被忽略的是：克隆不是“一键恢复”，而是一套需严格对齐的原子操作链——插件状态、权限分治、目录原子性、UUID 语义、GTID 连续性，任意一环松动，TB级数据就卡在半途不动，既不报错也不推进。动手前先跑通最小闭环（比如 1 GB 库 + 本地克隆），再放大规模。
