Slave_IO_State卡在“Connecting to source”本质是I/O线程反复connect()失败陷入重试循环，未发出首个MySQL协议包；需排查TCP可达性、bind-address/skip-networking配置、REPLICATION SLAVE权限、host匹配、caching_sha2_password兼容性、server_uuid唯一性及主库磁盘I/O饱和。
Slave_IO_State卡在“Connecting to source”本质是协议层失败
这不是“正在连接”，而是 I/O 线程反复调用 connect() 失败后陷入重试循环——它甚至没发出去第一个 MySQL 协议包。TCP 层通（telnet 成功）≠ MySQL 层可连，常见断点在 bind、权限、插件或 server_uuid 上。
主库监听配置错误：bind-address 和 skip-networking 最常被忽略
主库只监听 127.0.0.1 或启用了 skip-networking，会导致从库 IP 完全无法建立 TCP 连接，但 telnet 仍可能成功（比如你在主库本机测）。
- 在主库执行
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 master_ip -u repl -p 登录，不代表这个用户能做复制；REPLICATION CLIENT 权限不够，'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） - MySQL 8.0+ 默认用
caching_sha2_password插件，若主库未启用 SSL，需在主库执行：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，从库收不到数据 -
Last_IO_Error为空 ≠ 没问题；务必在主库运行SHOW PROCESSLIST;，找User = system user+Command = Binlog Dump的线程，看其State是Sending binlog event还是长期挂起
真正麻烦的不是哪一步错，而是多个条件同时满足才让复制跑起来：TCP 可达、MySQL 监听、用户存在且权限正确、host 匹配、密码无空格、插件兼容、server_uuid 唯一、磁盘不堵——漏掉任意一个，Slave_IO_State 就卡在 Connecting，且多数情况下 Last_IO_Error 不报或报得极隐晦。
