必须先执行SELECT @@log_error;获取真实路径，如/var/lib/mysql/hostname.err或/var/log/mysql/error.log；若实例未启动，则查配置文件my.cnf中log_error配置或默认datadir下的hostname.err。
查 MySQL 错误日志路径本身就得先连上实例
很多运维一上来就翻 /var/log/mysqld.log，结果发现文件空或权限被拒——因为 MySQL 实例根本没起来，或者你连的是错的实例。必须先确认当前 mysqld 进程实际加载的错误日志路径：
执行 SELECT @@log_error;，返回值才是真实路径。常见情况包括：
• 返回 /var/lib/mysql/hostname.err（默认 datadir 下）
• 返回 /var/log/mysql/error.log（某些 Debian/Ubuntu 包管理安装）
• 返回 stderr（Docker 容器中未挂载日志卷时，错误直接输出到容器 stdout）
克隆失败时最该盯住的三类错误信息
CLONE INSTANCE 失败不会只报一个错误，而是分阶段暴露问题。优先 grep 这三类关键词：
-
ER_CLONE_DONOR_NOT_FOUND：不是网络不通，是 recipient 上没设clone_valid_donor_list，或 donor 地址格式错（比如写了http://192.168.1.5:3306） -
ERROR 3095 (HY000): Insufficient privileges：recipient 用户缺CLONE_ADMIN（只给BACKUP_ADMIN不行），或 donor 用户没BACKUP_ADMIN -
ERROR 1126 (HY000): Can't open shared library 'mysql_clone.so'：插件根本没加载，不是权限问题——查SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'clone';，结果为空或DISABLED
远程克隆卡住不动？别只看 MySQL 日志
CLONE INSTANCE 远程执行时“卡住”，往往不是 MySQL 层面在等，而是底层 TCP 连接没建起来。这时错误日志里可能只有几行 INFO，甚至完全没记录。必须同步检查：
- donor 端是否监听了正确地址：
netstat -tlnp | grep :3306，确认0.0.0.0:3306或具体内网 IP，而非127.0.0.1:3306 - recipient 能否 telnet 通 donor 的 3306：
telnet 192.168.1.5 3306，不通就查防火墙、云安全组、SELinux（setenforce 0临时验证） - donor 的
max_connections是否耗尽：克隆会占用一个连接，若已满，recipient 就会一直 hang 在握手阶段，日志无报错
克隆后实例起不来？auto.cnf 是第一嫌疑对象
CLONE INSTANCE 执行完，recipient 自动重启失败，错误日志里反复出现 Failed to initialize GTID state 或 server_uuid is not unique，基本可以锁定是 auto.cnf 没清理干净。这不是日志“没报错”，而是报错太靠后——MySQL 启动流程中，读取 auto.cnf 是非常早的步骤，一旦 server_uuid 冲突，后续初始化直接终止，日志里可能只有一两行 warning。
正确做法是：克隆完成后、启动前，立刻进 recipient 数据目录删掉它：rm -f /var/lib/mysql/auto.cnf
再启动 mysqld，它会自动生成新 server_uuid。不删就启，99% 启动失败，且错误信息藏得深，容易误判为磁盘或权限问题。
