答案是先查last_io_error定位根因：若提示“equal mysql server uuids”，说明auto.cnf中server-uuid重复，需停服删除该文件后重启生成新uuid；同时须核验server-id唯一性及复制用户鉴权插件兼容性。
先看 Last_IO_Error，别急着 START SLAVE。MySQL 主动停掉 I/O 线程，说明连接已中断或校验失败，直接重启线程只会反复报错。
查 Last_IO_Error 才是第一动作
执行 SHOW SLAVE STATUS\G 后，跳过 Seconds_Behind_Master 和 Slave_IO_Running 字段，直接定位 Last_IO_Error 行——它是唯一可信的线索。
- 如果显示
Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs：说明auto.cnf中的server-uuid重复，常见于克隆虚拟机、Docker 镜像复用、直接拷贝数据目录 - 如果显示
Access denied for user 'repl'@'xxx'：主库上该用户没授权从库 IP，或CHANGE MASTER TO里密码写错了 - 如果显示
error connecting to master：检查主库bind_address是否监听了从库可访问的地址（比如写成127.0.0.1就会拒绝远程连接） - 如果为空或只提示
connection lost：优先怀疑server-uuid冲突或authentication plugin不兼容（尤其 MySQL 8.0+ 与旧客户端混用时）
修复 server-uuid 冲突最稳妥的做法
server-uuid 存在 /var/lib/mysql/auto.cnf（或你自定义的数据目录下），它由 MySQL 启动时生成，不能靠改配置文件生效。
- 停服务：
systemctl stop mysqld - 删文件：
rm -f /var/lib/mysql/auto.cnf（推荐，比手动改 UUID 更可靠） - 启动服务：
systemctl start mysqld，MySQL 会自动生成新server-uuid - 验证：
mysql -e "SHOW VARIABLES LIKE 'server_uuid';"，确认和主库不一致
注意：Docker 环境必须确保 /var/lib/mysql 是独立卷，否则容器重建后又会复用旧 auto.cnf。
别漏掉 server-id 和鉴权插件
server-id 冲突也会导致类似报错，但错误信息明确带 server ids 字样；而 authentication plugin 问题常被忽略：
- 查主库复制用户插件：
SELECT user, host, plugin FROM mysql.user WHERE user = 'repl'; - 若从库是 MySQL 5.7 或更低版本，主库用户必须用
mysql_native_password插件，执行：ALTER USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'; - 若从库 ≥ 8.0，且主库用户是
mysql_native_password，则需改成caching_sha2_password - 改完务必执行：
FLUSH PRIVILEGES;
这些点都检查完再 START SLAVE，否则可能刚启动就又变 No。
真正麻烦的不是报错本身，而是多个冲突点可能同时存在——比如克隆虚拟机既复制了 auto.cnf，又沿用了相同的 my.cnf 里的 server-id，还用了不匹配的鉴权插件。动手前先 SHOW VARIABLES LIKE 'server%'; 和 SHOW SLAVE STATUS\G 对着看，比盲目操作快得多。
