先查Last_IO_Error：若提示“equal MySQL server UUIDs”，需停服删除auto.cnf后重启生成新UUID；若为“Access denied”则核验复制用户权限与密码；若报错1236或找不到日志文件，需同步主库当前binlog位置并重置复制起点。
先看 Last_IO_Error，别急着 START SLAVE
MySQL 主动停掉 I/O 线程，说明连接已中断或校验失败，直接 START SLAVE 只会让线程反复报错、立刻退出。真正该做的第一件事是执行 SHOW SLAVE STATUS\G，然后跳过 Seconds_Behind_Master 和运行状态字段，直奔 Last_IO_Error 行——它是唯一可信的线索。
Last_IO_Error 提示 “equal MySQL server UUIDs” 怎么办
这是克隆部署后最常见的问题：从库复刻了主库的 /var/lib/mysql/auto.cnf 文件，导致双方 server-uuid 完全一致。MySQL 会主动拒绝复制连接。
- 停掉从库 MySQL 服务：
systemctl stop mysqld（或对应命令） - 找到并删除
/var/lib/mysql/auto.cnf（路径可用find / -iname auto.cnf 2>/dev/null确认） - 重启服务：
systemctl start mysqld，MySQL 会自动生成新server-uuid - 验证：
SELECT @@server_uuid;，确认与主库不重复
注意：server-id 也必须唯一且非 0，检查双方 my.cnf 中 [mysqld] 段配置，避免同时为 1 或 0。
Last_IO_Error 显示 “Access denied” 或 “error connecting to master”
这类错误和鉴权、网络、监听地址强相关，不是改个配置就能解决。
- 若提示
Access denied for user 'repl'@'x.x.x.x'：在主库执行SELECT host, user FROM mysql.user WHERE user = 'repl';，确认该用户允许从从库 IP 登录；如果密码刚改过，需同步更新CHANGE MASTER TO MASTER_PASSWORD='xxx' - 若提示连接失败（如
error connecting to master 'repl@192.168.1.10:3306'）：检查主库bind_address是否设为127.0.0.1或localhost——这会拒绝所有远程连接；应改为0.0.0.0或具体内网 IP - 检查防火墙是否放行 3306 端口，以及从库能否
telnet 192.168.1.10 3306通
Last_IO_Error 是 error 1236 或 “Could not find first log file name”
说明主库 binlog 文件已被清理，或从库记录的 MASTER_LOG_FILE 在主库上已不存在。这不是权限或 UUID 问题，而是日志断档。
- 在主库执行
SHOW MASTER STATUS;，记下当前File和Position - 在从库先停复制：
STOP SLAVE; - 重置复制起点：
CHANGE MASTER TO MASTER_LOG_FILE='<code>File', MASTER_LOG_POS=Position; - 再启动：
START SLAVE; - 若 GTID 模式启用，不能只靠
CHANGE MASTER TO，需配合SET GTID_NEXT和gtid_purged重置，否则会跳过关键事务
磁盘损坏也可能触发类似错误（如 Last_IO_Error 含 I/O error 或 Bad file descriptor），此时要查 dmesg -T 和 MySQL 错误日志，确认是否硬件故障——这种情况下修复配置无意义，得先换盘。
