主库和从库的server_uuid相同导致复制失败，需先通过show variables like 'server_uuid'确认冲突，再删除从库auto.cnf文件并重启服务生成新uuid。
查日志先看 Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs
这句话不是警告，是明确告诉你：主库和从库的 server_uuid 一模一样。MySQL 5.6+ 强制要求每个实例必须有唯一 server_uuid，否则主库直接拒绝从库连接请求，I/O 线程连握手都失败，直接停摆。
别急着改配置或重启，先确认是不是这个原因：
- 在主库执行
SHOW VARIABLES LIKE 'server_uuid'; - 在从库执行同样命令，对比输出值
- 再查错误日志：
grep -i "server.uuid" /var/log/mysqld.log，看是否匹配上述错误信息
auto.cnf 文件被克隆虚拟机带过去了
绝大多数 UUID 冲突都源于 VMware/VirtualBox 克隆操作——auto.cnf 是初始化时生成、写死在数据目录里的，克隆后原样保留，导致新实例和原主库 UUID 完全一致。
常见位置（按优先级排查）：
-
/var/lib/mysql/auto.cnf（标准安装默认路径） -
/data/mysql/auto.cnf（自定义datadir时） -
/usr/local/mysql/data/auto.cnf（源码编译安装）
注意：find / -name auto.cnf 2>/dev/null 可能扫出多个，但只有 MySQL 实际加载的那个才生效。别只删一个就以为完事。
删 auto.cnf 比手动改 UUID 更可靠
手动编辑 auto.cnf 改 server-uuid=... 容易输错格式（必须是 8-4-4-4-12 小写十六进制），且若文件权限不对、MySQL 启动时读取失败，仍会 fallback 到旧值。
推荐做法（从库上执行）：
- 停服务：
systemctl stop mysqld - 删文件：
rm -f /var/lib/mysql/auto.cnf（路径按你实际找到的来） - 启动服务：
systemctl start mysqld - 验证：
mysql -e "SHOW VARIABLES LIKE 'server_uuid';"，确认已生成新值
删掉后 MySQL 会在下次启动时自动生成合法 UUID，比手动生成更稳。
别漏掉 server-id 和 binlog 配置
server_uuid 冲突是最常见的原因，但不是唯一原因。如果删了 auto.cnf 还是报错，继续排查：
-
server-id是否重复？检查/etc/my.cnf中的server-id，主从必须不同，且不能为 0 - 主库是否开了 binlog？执行
SHOW VARIABLES LIKE 'log_bin';，返回ON才行 - 从库连接主库的用户是否有
REPLICATION SLAVE权限？执行SHOW GRANTS FOR 'repl_user'@'从库IP'; -
Master_Log_File和Read_Master_Log_Pos是否指向已删除的 binlog？用SHOW BINARY LOGS;在主库核对
真正麻烦的是混合问题：比如克隆导致 UUID 冲突，又恰好 server-id 没改，日志里可能只报一个错误，但修复要分步来。先解决 UUID，再看是否还有别的拦路虎。
