slave_io_running为no且last_io_error提示连接失败，90%因防火墙未放行或复制用户权限错误：先用telnet或test-netconnection验证从库到主库3306端口连通性，再检查主库防火墙及云平台安全组，并确认'repl'@'%'已授replication slave权限且flush privileges。
从库 Slave_IO_Running 为 No，且 Last_IO_Error 明确提示连接失败（如 Can't connect to MySQL server 或 Access denied），90% 是防火墙没放行或复制用户权限不对——别改 my.cnf，先做这两件事。
从库 telnet 主库 3306 端口不通怎么办
这是最常被跳过的一步。即使 CHANGE MASTER TO 成功、SHOW SLAVE STATUS 看起来配置都对，只要底层 TCP 连不上，I/O 线程就卡在 No 或 Connecting。
- 在从库服务器上执行：
telnet 主库IP 3306（Linux/macOS）或Test-NetConnection -ComputerName 主库IP -Port 3306（PowerShell） - 如果超时或报
Connection refused，说明连接根本没发出去——不是 MySQL 配置问题，是网络层被拦了 - 必须同时检查两处防火墙：
– 主库本机防火墙（firewalld或ufw）
– 云平台安全组（阿里云/腾讯云/AWS 控制台里“入方向规则”） - 注意：
bind-address = 0.0.0.0且skip-networking = OFF只是前提，不等于端口就对外可连；ss -tuln | grep :3306必须看到LISTEN才算监听成功
复制用户没有 REPLICATION SLAVE 权限怎么验证和修复
网络通了但还是报 Access denied for user 'repl'@'xxx'，大概率是账号权限或 host 匹配失败。MySQL 的 host 字段必须精确匹配从库发起连接时用的 IP 或域名。
- 登录主库，查账号是否存在且 host 正确：
SELECT user, host FROM mysql.user WHERE user = 'repl'; - 如果返回
'repl'@'localhost'，那它只能本机连——从库远程连接必然失败 - 正确授权方式（假设用
repl用户）：CREATE USER 'repl'@'%' IDENTIFIED BY 'strongpass';GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';FLUSH PRIVILEGES; - 验证是否生效：直接在从库服务器上用 mysql 命令连一次主库：
mysql -h 主库IP -u repl -p，能登录才说明权限和网络都 OK
为什么 SHOW SLAVE STATUS\G 里 Last_IO_Error 有时不报错但 Slave_IO_Running 仍是 No
这通常意味着 I/O 线程启动过、但很快异常退出，错误日志没来得及刷进状态字段。此时不能只盯 SHOW SLAVE STATUS，得看主库和从库的错误日志。
- 主库错误日志（路径由
SHOW VARIABLES LIKE 'log_error';查）里可能有：Too many connections（主库max_connections耗尽）、Access denied for user（但没传到从库状态里） - 从库错误日志里可能有：
Failed to initialize master info structure（master.info文件损坏）、SSL connection error（如果启用了 SSL 复制但证书不匹配） - 一个快速确认法：手动启动 I/O 线程后立刻查日志：
START SLAVE IO_THREAD;，然后tail -f /var/log/mysql/error.log看实时输出
真正卡住的地方往往不在复制配置本身，而在「谁允许这个连接进来」和「谁允许这个用户干这件事」——网络策略和权限模型是两个独立关卡，漏掉任何一个，Slave_IO_Running 就永远是 No。
