先确认last_io_errno为13117或1593且last_io_error含“equal mysql server uuids”，再比对主从server_uuid是否一致；若重复，须停服修改auto.cnf中server-uuid并重启，执行reset slave all后重配复制。
连接失败不是单一问题，而是几类互不干扰的故障叠加的结果。先看 Last_IO_Errno 和 Last_IO_Error，再查 server_uuid、server_id、网络通路、认证插件这四块，95% 的连接失败能当场定位。
怎么看错误码和错误信息才不绕弯？
别只扫一眼 SHOW SLAVE STATUS\G 就动手改配置。重点盯这两项：
-
Last_IO_Errno是数字，直接对应故障类型：13117或1593→ UUID 冲突；2003、2061→ 网络或认证问题；1236→ 主库 binlog 缺失或位置错 -
Last_IO_Error字段里带"equal MySQL server UUIDs"就是 UUID 重复；含"Authentication plugin"就是插件不兼容；出现"Can't connect to MySQL server"且没提密码，基本是端口不通或监听地址写成127.0.0.1 - 顺手执行
SELECT @@server_id, @@server_uuid;，主从比对——server_id相同会报Error 1236，server_uuid相同报13117，两者互不影响，得分别验
UUID重复必须改auto.cnf，不能跳过
MySQL 8+ 里，UUID 冲突不是“连接慢”，而是硬性拒绝。任何试图用 SET GTID_NEXT 或 RESET SLAVE 绕过的操作都会失败，甚至导致数据错乱。
- 先停服务：
sudo systemctl stop mysql（Docker 用docker stop mysql-slave） - 找真实
auto.cnf：运行mysql -e "SELECT @@datadir;"，再进该目录确认；若不确定，全盘搜find / -name auto.cnf 2>/dev/null - 生成新值覆盖：
echo "server-uuid=$(uuidgen)" > /var/lib/mysql/auto.cnf—— 别手动拼、别清空文件、别只改最后几位 - 重启后必须执行
RESET SLAVE ALL;（注意是ALL），否则旧复制元数据还在缓存里，START SLAVE仍会报错
server_id重复、监听地址写错、插件不匹配这三类最容易漏查
它们看起来像“配置问题”，但实际表现和 UUID 冲突高度相似：都是 IO_Running: Connecting + Seconds_Behind_Master: NULL，容易误判为网络抖动。
-
server_id必须全局唯一且非零，检查方式：SELECT @@server_id;，不是看配置文件——动态改过就以运行时为准 - 主库
bind-address不能是127.0.0.1，得设成0.0.0.0或具体内网 IP；从库CHANGE MASTER TO的MASTER_HOST也不能填localhost - MySQL 8.0+ 默认用
caching_sha2_password，但很多从库客户端不支持加密协商。主库执行：ALTER USER 'repluser'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'; FLUSH PRIVILEGES;
Docker环境改auto.cnf常失效，得换思路
容器里改完 auto.cnf 重启发现 server_uuid 没变？说明文件被挂载卷、ConfigMap 或镜像层覆盖了。
- 验证方法：启动后立刻对比
cat /var/lib/mysql/auto.cnf和SELECT @@server_uuid;是否一致，不一致就是被覆盖 - 宿主机方案：在映射目录里提前生成好
auto.cnf，再启动容器；别等容器起来再docker exec改 - 初始化脚本方案：在容器
ENTRYPOINT里加判断，如果/var/lib/mysql/auto.cnf不存在或内容为空，就echo "server-uuid=$(uuidgen)" > /var/lib/mysql/auto.cnf
真正麻烦的不是改哪一行配置，而是你改完之后没清掉旧的复制上下文——RESET SLAVE ALL 这一步漏掉，前面所有操作都白做；Docker 里文件被覆盖却没意识到，又回头反复改配置。这些点不踩一遍，很难真正记住。
