slave_io_running: connecting 表示i/o线程反复connect()失败并死循环重试，尚未发出mysql协议包；需立即查last_io_error、手动mysql连接复现，并排查bind-address、权限、server_uuid重复及磁盘i/o等静默故障点。
Slave_IO_Running: Connecting 不是“正在连”，是连不上卡在重试循环里
这个状态根本不是进度条，而是 I/O 线程反复调用 connect() 失败后死循环重试——它甚至没发出第一个 MySQL 协议包。TCP 层通（telnet 主库IP 3306 成功）≠ MySQL 层可连，常见断点在配置、权限、插件或底层 I/O。
必须立刻查 Last_IO_Error（哪怕为空），再配合手动复现：
- 在从库执行 mysql -h 主库IP -P 3306 -u repl -p，比 telnet 更贴近真实连接流程
- 若失败，错误信息比 SHOW SLAVE STATUS 里的更直接
主库 bind-address 或 skip-networking 配置错误
这是最常被忽略的 TCP 层拦截点。主库只监听 127.0.0.1 或启用了 skip-networking，会导致从库 IP 完全无法建连，但你在主库本机 telnet 127.0.0.1 3306 却能通，造成严重误判。
- 在主库执行
ss -tlnp | grep :3306，确认监听地址是0.0.0.0:3306或具体内网 IP，不是127.0.0.1:3306 - 检查主库
my.cnf：bind-address不能为127.0.0.1，且不能有skip-networking = 1 - 云环境额外检查安全组入方向规则——
firewalld放行了，不等于阿里云/AWS 控制台也开了
复制用户权限、密码或认证插件不兼容
能用 mysql -h 登录不代表能做复制：REPLICATION CLIENT 权限不够；'repl'@'%' 不一定匹配从库真实出口 IP；MySQL 8.0+ 默认 caching_sha2_password 插件在旧客户端或未配 SSL 时会静默失败。
- 在主库执行
SELECT user, host FROM mysql.user WHERE user = 'repl';，确认返回的是'repl'@'从库真实IP'或'repl'@'%'，而非'repl'@'localhost' - 执行
SHOW GRANTS FOR 'repl'@'从库真实IP';，确保含REPLICATION SLAVE（不是REPLICATION CLIENT） - MySQL 8.0+ 用户需显式切换插件：
ALTER USER 'repl'@'xxx' IDENTIFIED WITH mysql_native_password BY 'xxx'; - 密码末尾多一个空格（如
MASTER_PASSWORD='pass '）会导致认证失败且Last_IO_Error为空
server_uuid 重复或主库磁盘 I/O 饱和导致无声卡死
这两个问题不会报明显错误，但会让状态永远停在 Connecting，极易被当成网络故障处理错方向。
- 在主库和从库分别执行
SHOW VARIABLES LIKE 'server_uuid';，若值相同（常见于克隆虚拟机后未清理/var/lib/mysql/auto.cnf），必须停库 → 删除该文件 → 重启mysqld - 主库磁盘写满或
iostat -xmd 1显示%util > 95%且await > 20ms，说明Binlog Dump线程卡在Writing to net，从库收不到响应，I/O 线程超时后不断重试 - 在主库执行
SHOW PROCESSLIST;，找User = system user、Command = Binlog Dump的线程，看State是Sending binlog event还是长期卡住
真正难排查的，是那些不报错却让状态卡死的点：比如 server_uuid 重复、磁盘 I/O 饱和、或 caching_sha2_password 在未启用 SSL 的场景下静默拒绝连接——这些地方没有错误日志，只有手动复现和底层指标交叉验证才能揪出来。
