Slave_IO_Running: Connecting 表示I/O线程未建立TCP连接，仅在重试循环中失败；本质是网络不通、认证失败或配置错误导致无法进入MySQL协议层，需结合Last_IO_Error、telnet、mysql客户端测试及权限、防火墙、bind-address等逐层排查。
Slave_IO_Running: Connecting 的本质含义
这个状态不是“正在努力连接”，而是“尝试连接失败后卡在重试循环里”——MySQL从库的I/O线程根本没建立TCP连接，连认证环节都没进入。它反复发起connect()系统调用，但每次都被拒绝或超时，于是停留在Connecting状态不动。真正该看的是SHOW SLAVE STATUS\G里的Seconds_Behind_Master和Last_IO_Error字段，但很多时候Last_IO_Error为空，这就更需要主动排查底层连通性。
telnet 或 nc 能通，不代表 MySQL 就能连上
常见误区是只执行telnet master_ip 3306成功就认为网络OK。但实际可能：主库bind-address配置为127.0.0.1，导致只监听本地；主库启用了skip-networking；或者MySQL服务监听在非标准端口（如3307），而change master语句里写的是默认3306。
- 确认主库真实监听地址：
ss -tlnp | grep mysqld或netstat -tlnp | grep :330 - 检查
my.cnf中是否含bind-address = 0.0.0.0（或具体IP）且未被skip-networking覆盖 - 从库执行
mysql -h master_ip -P port -u repl -p手动测试，比telnet更贴近真实场景
复制用户权限缺失比密码错误更隐蔽
即使mysql -u repl -p -h master_ip能登录，也不代表它有复制权限。MySQL复制要求用户必须显式拥有REPLICATION SLAVE权限，且host字段要匹配从库发起连接的真实IP（不是%通配符被防火墙/NAT扭曲后的IP）。
- 在主库查用户来源：
SELECT user, host FROM mysql.user WHERE user = 'repl'; - 确认权限：
SHOW GRANTS FOR 'repl'@'从库真实IP';（注意不是'repl'@'%'） - 若用
'repl'@'%'，需确保主库max_connect_errors未被触发封禁（查SHOW VARIABLES LIKE 'max_connect_errors';，被封时会报Host is blocked） - 授权命令必须包含
REPLICATION SLAVE，仅REPLICATION CLIENT不够
防火墙策略常被低估的两个细节
关掉firewalld或ufw只是第一步。很多环境还叠加了iptables规则、云平台安全组、宿主机防火墙（如VirtualBox/VMware NAT模式下额外限制），甚至SELinux的mysqld_can_network_connect布尔值未开启。
- 主库执行
iptables -nL | grep 3306，确认INPUT链允许从库IP访问目标端口 - 云服务器务必检查控制台里的安全组规则，开放对应端口+源IP段（别只放
0.0.0.0/0） - SELinux环境下运行
getsebool -a | grep mysql，若mysqld_can_network_connect为off，需执行setsebool -P mysqld_can_network_connect on - 重启MySQL服务后，
change master前务必先stop slave;，否则旧连接参数仍缓存
最易被忽略的一点：所有排查必须在**主库真实IP与端口完全确定**的前提下进行。人工输错IP（比如把192.168.196.129写成192.168.126.129）、端口填错、server-id重复这些低级错误，在压力操作时高频出现，且日志里不报明确错误。
