slave_io_running为no时，必须先查last_io_error定位原因，再针对性修复：网络、权限、server-id冲突、authentication plugin不兼容、auto.cnf中server-uuid重复、master_log_file配置错误等均会导致io线程主动停止。
Slave_IO_Running: No 时先看 Last_IO_Error 而不是直接 START SLAVE
线程停了不是“丢了”，是 MySQL 主动中止连接，必须从 Last_IO_Error 入手。执行 SHOW SLAVE STATUS\G 后，跳过 Seconds_Behind_Master 和运行状态字段，直奔 Last_IO_Error 行——它才是唯一可信的线索。
常见错误类型和对应动作：
-
Last_IO_Error: error connecting to master 'repl@192.168.1.10:3306'→ 检查网络连通性、防火墙、主库bind_address是否监听了从库可访问的 IP（比如写成127.0.0.1或localhost就会拒绝远程连接） -
Last_IO_Error: Access denied for user 'repl'@'192.168.1.20'→ 主库上执行SELECT host, user FROM mysql.user WHERE user = 'repl';，确认该用户是否允许从从库 IP 登录；密码变更后未同步更新CHANGE MASTER TO中的MASTER_PASSWORD也会触发此错 -
Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids→ 说明主从server-id冲突，检查双方my.cnf的[mysqld]段，确保不重复且非 0
鉴权失败时，别只改密码，还要核对 authentication plugin
MySQL 8.0+ 默认使用 caching_sha2_password 插件，而旧版客户端或复制用户若仍用 mysql_native_password 创建，就会在 IO 线程建立连接时静默失败，Last_IO_Error 可能只显示 “authentication plugin” 相关提示。
修复步骤：
- 登录主库，查用户插件：
SELECT user, host, plugin FROM mysql.user WHERE user = 'repl'; - 若插件不是
caching_sha2_password，且你确认从库 MySQL 版本 ≥ 8.0，执行：ALTER USER 'repl'@'%' IDENTIFIED WITH caching_sha2_password BY 'xxx'; - 如果从库是 5.7 或更低版本，主库应改用兼容插件：
ALTER USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'; - 执行
FLUSH PRIVILEGES;，再在从库上重试START SLAVE;
auto.cnf 中 server_uuid 重复会导致 Slave_IO_Running 卡在 Connecting 或直接变 No
Docker 克隆、VM 快照、物理机重装后直接拷贝数据目录——这些操作极易让从库的 /var/lib/mysql/auto.cnf 和主库一模一样。MySQL 启动时读取该文件生成唯一标识，一旦重复，IO 线程拒绝连接，Last_IO_Error 可能为空或仅提示 “connection lost”。
验证与修复方法：
- 查当前 UUID：
SHOW VARIABLES LIKE 'server_uuid';，对比主从输出是否一致 - 定位配置文件：
find / -iname "auto.cnf" 2>/dev/null（常见路径为/var/lib/mysql/auto.cnf） - 停库后手动编辑该文件，修改
server-uuid值（保持格式为 8-4-4-4-12 十六进制，如123e4567-e89b-12d3-a456-426614174000），确保与主库不同 - 重启 mysqld：
systemctl restart mysqld（Docker 环境则需docker restart容器） - 再执行
START SLAVE;，观察Slave_IO_Running是否变为Yes
CHANGE MASTER TO 中 MASTER_LOG_FILE 错误或缺失会直接拒绝 IO 连接
GTID 关闭时，MASTER_LOG_FILE 和 MASTER_LOG_POS 必须严格匹配主库 SHOW MASTER STATUS 输出。差一个字符、文件名大小写不一致（如 mysql-bin.000001 vs MYSQL-BIN.000001）、或指向已被 PURGE 的 binlog，都会让 IO 线程启动即失败，Last_IO_Error 显示 “Could not find first log file name in binary log index file” 或 “The specified log file does not exist”。
安全检查项：
- 主库执行
SHOW BINARY LOGS;，确认MASTER_LOG_FILE在列表中存在 - 主库执行
SHOW MASTER STATUS;，比对File和Position字段，注意不要复制出多余的空格 - 若从库已断开较久，主库 binlog 被自动清理（
expire_logs_days生效），不能硬靠位点追，应考虑切换 GTID 模式重建，或用mysqldump --dump-slave=2导出从库当前所知的主库位点 - GTID 模式下禁止指定
MASTER_LOG_FILE，否则报错ERROR 1777 (HY000)；此时应设MASTER_AUTO_POSITION=1并清空日志文件相关参数
最易被忽略的是：auto.cnf 改完不重启 mysqld，或改完 UUID 后没清空 relay log（RESET SLAVE 会删掉 relay-log.info，但不会删物理 relay log 文件，残留文件可能干扰新连接）。问题常卡在这两步之间，而不是配置本身。
