Slave_IO_Running: Connecting 表示I/O线程未建立TCP连接，仅在重试循环中失败；本质是网络不通、认证失败或配置错误导致无法进入MySQL协议层，需结合Last_IO_Error、telnet、mysql客户端测试及权限、防火墙、bind-address等逐层排查。
MySQL
编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。
下载
Slave_IO_Running: Connecting 不代表“正在连接中”，而是 I/O 线程反复调用
connect() 失败后卡在重试循环里——它根本没建立 TCP 连接，更没走到 MySQL 认证阶段。真正要盯的是
Last_IO_Error（常为空）、
telnet 结果、以及主库是否真在监听。
从库连不上主库：先验证 TCP 层通不通
telnet 或
nc -zv 能通 ≠ MySQL 可连，但不通就一定失败。别跳过这步。
- 在从库执行
telnet 主库IP 3306；超时或 Connection refused，说明网络/防火墙/监听配置三者至少一个有问题
-
ss -tlnp | grep :3306 在主库运行，必须看到 LISTEN 状态，且监听地址不是 127.0.0.1（否则只接受本地连接）
- 检查主库
my.cnf：确认 bind-address = 0.0.0.0（或具体内网 IP），且未被 skip-networking 覆盖
- 云环境务必查安全组——firewalld/ufw 放行了，不等于阿里云/AWS 控制台的入方向规则也放行了
主库监听正常但还是连不上：复制用户权限最常踩坑
能
mysql -h 主库IP -u repl -p 登录，不等于有复制权限；
'repl'@'%' 也不等于能匹配从库真实出口 IP。
- 在主库执行
SELECT user, host FROM mysql.user WHERE user = 'repl';，确认返回的是 'repl'@'从库真实IP' 或 'repl'@'%'，而不是 'repl'@'localhost'
- 执行
SHOW GRANTS FOR 'repl'@'从库真实IP';（注意不是 %），确保包含 REPLICATION SLAVE —— REPLICATION CLIENT 不够
- 若用
'repl'@'%'，检查是否触发 max_connect_errors 封禁：SHOW VARIABLES LIKE 'max_connect_errors';，被封时错误日志会报 Host is blocked
- MySQL 8.0+ 默认用
caching_sha2_password 插件，若主库未启用 SSL 且从库未配 MASTER_SSL=1，会报错 ERROR 2061 并卡在 Connecting
网络和权限都 OK，但状态仍卡住：看主库 binlog dump 线程是否真在干活
telnet 通、
mysql 命令能登录、
Last_IO_Error 为空，不代表没问题——主库磁盘 I/O 或网络发送可能已饱和。
- 在主库执行
SHOW PROCESSLIST;，找 User = system user、Command = Binlog Dump 的线程，看 State 是 Sending binlog event 还是长期卡在 Writing to net
- 主库跑
iostat -xmd 1：若 %util > 95% 且 await > 20ms，说明磁盘写不过来，binlog dump 线程读不到新日志
- 从库跑
iftop -P 3306 -f "host 主库IP"：若流量间歇性归零（比如 40MB/s → 0 → 40MB/s），不是丢包，而是从库 SQL 线程消费太慢，TCP 窗口缩为 0 反压回主库
-
Seconds_Behind_Master 跳变剧烈（如 5s → 120s → 30s）+ Read_Master_Log_Pos 增长缓慢，基本可锁定为主库 I/O 瓶颈
Slave_IO_Running: Connecting 看似简单，实际横跨网络层、MySQL 协议层、权限校验层、系统资源层。最容易被忽略的是：主库磁盘 I/O 饱和时，
telnet 和
mysql 命令全都能通，但复制就是不动——因为
binlog dump 线程根本读不到数据。
