克隆失败前的error日志关键字段包括error 3095（权限错位）、error 3865（插件未启用）、error 3707（重启失败）、“too many concurrent clone operations”（并发阻塞）及“insufficient privileges”，每个均对应明确故障层，需结合plugin状态、server_uuid、datadir清空情况等交叉验证。
查克隆失败前的ERROR日志关键字段
克隆失败时，MySQL错误日志（通常是 /var/log/mysqld.log 或 /var/lib/mysql/hostname.err）里不会直接写“克隆失败”，而是埋着几类高概率线索：ERROR 3095、ERROR 3865、ERROR 3707、too many concurrent clone operations、Insufficient privileges。这些不是泛泛报错，每个都对应明确故障层：
-
ERROR 3095 (HY000)：权限配置错位——donor 上缺BACKUP_ADMIN，或 recipient 上缺CLONE_ADMIN，不是账号没登录，是角色没授全 -
ERROR 3865 (HY000)：donor 端插件根本没启用，不是网络不通，是SELECT PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME='clone'返回DISABLED -
ERROR 3707 (HY000)：recipient 克隆完自动重启失败，本质是 systemd 或 mysqld_safe 没被正确识别为监控进程，不影响数据完整性，但需手动systemctl restart mysqld - 反复出现
too many concurrent clone operations：不是磁盘或网络瓶颈，是clone_max_concurrency触发了阻塞，检查 donor 是否有其他 BACKUP 或 DDL 正在运行
确认插件加载是否真的成功
很多人执行了 INSTALL PLUGIN clone SONAME 'mysql_clone.so' 就以为万事大吉，但日志里看不到报错不等于插件就活了。真正要盯的是加载阶段的隐式失败：
- 启动时若
plugin_dir下没有mysql_clone.so，日志会安静地跳过，只在INFORMATION_SCHEMA.PLUGINS里显示DISABLED；先跑ls -l $(mysql -Nse "SELECT @@plugin_dir")/mysql_clone.so确认文件存在 - MySQL 进程用户（如
mysql）对mysql_clone.so缺少x权限，日志无提示，但strace -e trace=openat -p $(pgrep mysqld)会看到openat(..., "mysql_clone.so", ...) = -1 EACCES - SELinux 启用时拦截动态库加载，日志里只有
Failed to load plugin 'clone'这种模糊语句，需查ausearch -m avc -ts recent | grep clone看拒绝记录
远程克隆连不上 donor 的真实原因
报错 Can't connect to MySQL server on 'x.x.x.x' 或 Clone Donor error: The data directory is not empty，表面是连接或目录问题，实际常因配置错位：
-
clone_valid_donor_list必须在 donor 端显式设置，recipient 端设了没用；执行SET GLOBAL clone_valid_donor_list = '192.168.1.10:3306'后，立刻查SELECT @@clone_valid_donor_list确认生效 -
CLONE INSTANCE FROM 'user'@'ip':port中的user是 donor 端账号，不是当前登录账号；该账号必须已在 donor 上创建且有BACKUP_ADMIN，recipient 上不需要这个账号存在 - recipient 的
datadir非空时，克隆会直接中止并报错，但日志里可能只写Invalid argument—— 停 MySQL 后rm -rf /var/lib/mysql/*才算清干净，别信ls -A看不到就等于空
克隆后服务起不来，别急着重试
克隆完成、MySQL 自动重启失败（ERROR 3707）或启动后连不上，多数人第一反应是重跑克隆，但问题往往不在克隆本身：
- recipient 的
server_uuid和 donor 完全一样，会导致 GTID_PURGED 冲突，START SLAVE报错；必须改server_uuid（改完再重启），不能靠克隆覆盖 - 克隆拷贝的是物理文件，
mysql.user表里的caching_sha2_password用户在新实例上可能因客户端版本低而认证失败，得手动ALTER USER ... IDENTIFIED WITH mysql_native_password - innodb 表空间路径继承 donor 配置，若 recipient 的
innodb_data_home_dir指向非空目录，启动时会报Invalid tablespace file，必须确保该路径为空或为默认值
克隆是物理快照，不是逻辑重建；日志里最值得细看的，永远是那些看起来像“小问题”的提示——比如权限、路径、UUID、插件状态，它们比网络超时更常成为真正的拦路虎。
