Slave_IO_Running: No本质是从库无法连接主库，90%属连接层问题：需验证TCP端口可达性（非仅ping）、主库监听地址（非127.0.0.1）、防火墙/云安全组放行、复制用户插件兼容性（如caching_sha2_password）。
Slave_IO_Running: No 本质是「从库连不上主库」，不是数据同步逻辑出错，而是连接层断了。先别急着改 pos 或跳过事件，90% 的情况卡在连接建立环节。
检查网络连通性是否真实可靠
很多人用 ping 通了就认为网络没问题，但 MySQL 复制走的是 TCP 3306（或自定义端口），不是 ICMP。必须验证端口可达：
- 在从库机器上执行：
telnet 主库IP 3306或nc -zv 主库IP 3306—— 如果超时或拒绝连接，ping通也没用 - 确认主库防火墙放行了该端口：
firewall-cmd --list-ports（CentOS）或ufw status（Ubuntu） - 检查主库是否监听在正确地址：运行
ss -tlnp | grep :3306，看LISTEN行的 IP 是0.0.0.0还是127.0.0.1；若为后者，外部无法连接 - 云服务器注意安全组规则，尤其阿里云/腾讯云默认只放行内网或特定 IP 段
验证复制账号权限和认证方式
MySQL 8.0+ 默认使用 caching_sha2_password 插件，而旧版客户端或某些从库版本可能不兼容，导致 Error_code: 1045 —— 看似密码错，实为插件不匹配：
- 登录主库，查复制用户实际用的插件：
SELECT host, user, plugin FROM mysql.user WHERE user = 'repl_user'; - 如果 plugin 是
caching_sha2_password，且从库 MySQL 版本 ALTER USER 'repl_user'@'%' IDENTIFIED WITH mysql_native_password BY 'yourpass'; - 确保账号授权完整：
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%'; FLUSH PRIVILEGES;—— 注意不能只给REPLICATION CLIENT - 检查账号是否绑定了特定 host（如
'repl_user'@'192.168.1.%'），而从库实际出口 IP 不在此范围
确认 master.info 是否残留错误配置
从库重启后仍沿用旧的 master.info 文件，会导致 CHANGE MASTER TO 设置被覆盖，即使你改了配置也不生效：
- 该文件默认在 MySQL 数据目录下（如
/var/lib/mysql/master.info），记录了master_host、master_user、master_log_file等全部连接参数 - 若你已修正
my.cnf并执行过CHANGE MASTER TO，但状态仍是Connecting或No，直接删掉它：rm -f /var/lib/mysql/master.info - 删除后必须重启 MySQL 服务（不是仅
stop slave; start slave;），否则下次启动仍会重建旧内容 - 删之前可先备份：
cp /var/lib/mysql/master.info /tmp/master.info.bak
真正容易被忽略的点：server_uuid 冲突不会直接报连接失败，但它会让 IO 线程反复重连后静默失败，SHOW SLAVE STATUS 里 Last_IO_Error 可能为空或只写“Fatal error encountered during change user”——这时得去查 /var/lib/mysql/auto.cnf，而不是盯着网络和权限打转。
