克隆后UUID重复必须处理，因CLONE INSTANCE会完整复制auto.cnf且MySQL启动绝不覆盖它，导致主从复制直接失败（错误13117/1593）；正确做法是停服务→删auto.cnf→重启→再执行RESET SLAVE ALL和CHANGE MASTER TO。
克隆后UUID重复会直接导致主从复制失败，不是可选项，而是必须处理的硬性前提
CLONE INSTANCE 会原样复制 auto.cnf，而 MySQL 启动时绝不覆盖它
MySQL 8.0 的克隆插件（CLONE INSTANCE）执行的是物理级数据拷贝：整个数据目录被完整复制，包括 /var/lib/mysql/auto.cnf。这个文件里存着 server-uuid，且 MySQL 启动逻辑明确规定——只要该文件存在，就直接读取并使用其中的 UUID，绝不会重新生成或校验是否“合法”。所以克隆出的新实例和源实例 UUID 完全一致。
常见错误现象：
Last_IO_Error: Fatal error: The replica I/O thread stops because source and replica have equal MySQL server UUIDs-
SHOW SLAVE STATUS\G中Slave_IO_Running: No，且Seconds_Behind_Master为NULL
不能编辑 auto.cnf 文件内容，只能删掉让它重建
直接用 vim 修改 auto.cnf 里的 server-uuid 值是无效甚至危险的：
- MySQL 启动时会校验文件格式，非法 INI 结构会导致服务启动失败
- 运行中
rm该文件大概率失败——mysqld进程已独占锁定该文件 - 哪怕删了又手动新建一个空文件或软链接，MySQL 也会跳过生成新 UUID，最终
server_uuid变为空字符串或沿用旧值
正确做法只有一步：停服务 → 删文件 → 重启。删之前务必 cp /var/lib/mysql/auto.cnf /var/lib/mysql/auto.cnf.bak 备份。
验证新 UUID 是否生效，不能只看 SHOW VARIABLES
重启后必须做双重验证：
- 执行
SHOW VARIABLES LIKE 'server_uuid'—— 返回值应为标准格式（32 字符 + 4 短横线），且与主库不同 - 执行
cat /var/lib/mysql/auto.cnf—— 内容必须是合法 INI 格式，含[auto]段，且该文件是 MySQL 重启后全新生成的（可用stat /var/lib/mysql/auto.cnf看修改时间）
容易被忽略的关键点：如果克隆后没删 auto.cnf，但又执行了 RESET SLAVE ALL 或重配复制，server_uuid 依然不变——因为根本没触发重建逻辑。
用克隆插件搭从库，RESET SLAVE ALL 必须跟在 UUID 重置之后
克隆操作本身会把 donor 的 binlog 位点信息也一并写入 recipient 的 mysql.slave_master_info 表，但这些信息是 donor 的上下文。如果不先解决 UUID 冲突，后续任何 START SLAVE 都会立刻失败。
标准顺序必须是：
- 停
mysqld - 删
/var/lib/mysql/auto.cnf - 启
mysqld（此时新 UUID 已生成） - 登录后执行
STOP SLAVE; RESET SLAVE ALL; - 再
CHANGE MASTER TO ...设置正确的主库连接参数
跳过任意一步，尤其是把 RESET SLAVE ALL 放在删 auto.cnf 之前，都会让问题陷入死循环。
