CLONE插件不能用于“冷备”DDL变更，仅支持物理快照；8.0.27前克隆全程阻塞DDL，之后可通过clone_block_ddl控制，但recipient始终不支持DDL。
Clone 插件不能用于“冷备”DDL变更，也不能在克隆过程中执行 DDL；它只做物理快照，且对 DDL 敏感——要么禁止（8.0.26 之前），要么需显式控制（clone_block_ddl=ON）。
CLONE INSTANCE 会阻塞 DDL 吗？取决于版本和配置
MySQL 8.0.27 起默认允许 donor 端并发 DDL，但 recipient 端始终不支持 DDL 操作（克隆期间实例会被 SHUTDOWN）。关键变量是 clone_block_ddl：
- 设为
ON（默认值）：donor 上所有 DDL（包括TRUNCATE TABLE、DROP DATABASE）会被阻塞，直到克隆完成 - 设为
OFF：donor 允许 DDL，但可能引发克隆失败或数据不一致（如 DDL 中途删表，而克隆已读取部分元数据） - recipient 端无需也不应执行任何 DDL——克隆会覆盖整个数据目录，已有 schema/table 全部被清空
本地克隆是唯一能用于“库表DDL冷备”的可行路径
远程克隆（CLONE INSTANCE FROM）直接覆盖 recipient 的 datadir，无法保留原库结构做比对或回滚。只有本地克隆（CLONE LOCAL DATA DIRECTORY）能生成一份独立副本，供你人工检查 DDL 影响：
- 必须用绝对路径，且目标目录不能预先存在：
CLONE LOCAL DATA DIRECTORY = '/backup/mysql_pre_alter_20261014' - 克隆前确保
innodb_file_per_table = ON，否则遇到独立表空间会报ERROR 1086 (HY000): File 'xxx.ibd' already exists - 克隆后可启动新实例验证：
mysqld_safe --datadir=/backup/mysql_pre_alter_20261014 --port=3307 --socket=/tmp/mysql3307.sock - 注意：克隆不包含 binlog、slow log、audit log 等非 InnoDB 文件，也不备份 MyISAM 表真实数据（仅留空表结构）
为什么不能把 Clone 当作“DDL 变更的备份手段”？
Clone 是全量物理快照，不是增量或逻辑备份。它不记录“哪些表被改了”，也不保存 DDL 语句本身。如果你需要追溯 DDL 变更，真正该依赖的是：
-
mysqlbinlog解析 binlog（前提是log_bin=ON且未过期） -
performance_schema.events_statements_history_long（短期可查，重启即丢） - 外部审计工具或应用层 DDL 工单系统
Clone 唯一能做的，是在 DDL 执行前，快速拍下一份可立即启动的完整数据副本——但它本身不感知、不记录、不校验 DDL 语义。
容易被忽略的权限与路径陷阱
即使插件状态是 ACTIVE，本地克隆仍常因两个细节失败：
- 执行用户缺少
BACKUP_ADMIN权限（不是SELECT或REPLICATION SLAVE）：GRANT BACKUP_ADMIN ON *.* TO 'backup_user'@'localhost'; - 目标路径的父目录（如
/backup）属主不是mysql用户，导致 mysqld 无法创建子目录：chown mysql:mysql /backup
克隆完成后，/backup/mysql_pre_alter_20261014 目录里不会自动包含 my.cnf 或 server_id 配置——这些仍需你手动复制或重写，否则启动新实例会沿用原配置，可能引发端口冲突或 GTID 冲突。
