slave_io_running: no本质是从库无法连接主库，90%属连接层问题：需验证tcp端口可达性、主库监听地址非127.0.0.1、防火墙/云安全组放行、复制用户插件兼容性及server-uuid唯一性。
Slave_IO_Running: No 不是同步逻辑出错，而是从库根本连不上主库 —— 90% 的情况卡在连接建立环节，别急着改 pos 或跳过事件。
检查网络连通性与主库监听配置
很多人只用 ping 测试就认为网络没问题，但 MySQL 复制走的是 TCP 3306（或自定义端口），不是 ICMP。必须验证端口级连通性：
- 在从库执行
nc -zv 主库IP 3306或telnet 主库IP 3306；超时或拒绝连接，ping通也没用 - 登录主库，运行
ss -tlnp | grep :3306，确认 LISTEN 地址是0.0.0.0:3306或具体内网 IP，而非127.0.0.1:3306 - 检查主库防火墙：
ufw status（Ubuntu）或firewall-cmd --list-ports（CentOS），确保 3306/tcp 已放行 - 云服务器务必检查安全组规则（如阿里云/腾讯云），默认常只允许内网或特定 IP 段
验证复制账号权限与认证插件兼容性
MySQL 8.0+ 默认使用 caching_sha2_password 插件，而旧版从库客户端可能不支持，导致看似“密码错误”的 Error_code: 1045：
- 在主库执行
SELECT host, user, plugin FROM mysql.user WHERE user = 'repl_user';，确认插件类型 - 若为
caching_sha2_password且从库版本 ≤ 5.7 或未显式启用该插件，改用原生认证：ALTER USER 'repl_user'@'%' IDENTIFIED WITH mysql_native_password BY 'yourpass'; - 确保授权完整：
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'从库IP'; FLUSH PRIVILEGES;—— 注意不能只给REPLICATION CLIENT - 检查
host是否精确匹配：比如'repl_user'@'192.168.1.6'无法匹配从库实际出口 IP 是192.168.1.7的情况
排查 server-uuid 冲突与 master.info 残留配置
克隆虚拟机部署是最常见的隐形杀手：auto.cnf 中的 server-uuid 重复会导致 I/O 线程反复重连后静默失败，日志里往往只显示 Connecting 状态，不报明确错误：
- 在从库执行
find / -iname "auto.cnf" 2>/dev/null，通常路径为/var/lib/mysql/auto.cnf - 停止 MySQL：
systemctl stop mysqld，编辑该文件，修改server-uuid值（格式合法即可，如a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8），确保与主库及其他从库不重复 - 删除残留元数据：
rm -f /var/lib/mysql/master.info（删前可备份），否则CHANGE MASTER TO设置会被覆盖 - 重启服务：
systemctl restart mysqld，再执行START SLAVE;—— 仅STOP SLAVE; START SLAVE;无效
确认主库 binlog 启用与 SSL 配置一致性
主库未开 binlog 或强制 SSL 而从库未配，也会导致 I/O 线程无法启动，且错误信息极不直观：
- 主库执行
SHOW VARIABLES LIKE 'log_bin';，返回OFF就必须在my.cnf加log-bin = mysql-bin并重启 - 主库执行
SHOW VARIABLES LIKE 'require_secure_transport';，若为ON，则从库CHANGE MASTER TO必须加上MASTER_SSL=1及对应证书参数，否则连接被静默拒绝 - 查看
Last_IO_Error字段，哪怕只显示error connecting to master，也要结合上述两点交叉验证 —— 它不提示具体原因
真正容易被忽略的是：server-uuid 冲突和 master.info 残留不会直接报错，但会让所有修复动作失效；而 RESET SLAVE 后必须重新执行完整的 CHANGE MASTER TO，否则 START SLAVE 会因连接参数为空直接失败。
