mysql从库连不上主库，首要排查网络连通性：先用telnet或test-netconnection测试3306端口是否可达，再检查主库防火墙（系统级+云安全组）是否放行tcp 3306入站；其次验证复制用户权限是否授予replication slave且host匹配从库ip；最后确认主库已启用binlog、server-id唯一且非1冲突。
MySQL从库连不上主库：先看网络通不通
现象是 CHANGE MASTER TO 成功但 START SLAVE 后报错 ERROR 2003 (HY000): Can't connect to MySQL server，或 SHOW SLAVE STATUS\G 中 Slave_IO_Running: No、Seconds_Behind_Master: NULL、Last_IO_Error 提示连接拒绝。
这大概率不是复制配置问题，而是底层网络卡住了。别急着改 my.cnf 或重配权限，先确认从库能否“摸到”主库的 3306 端口：
- 在从库服务器上执行：
telnet 3306（Linux/macOS）或Test-NetConnection -Port 3306（PowerShell） - 如果超时或报
Connection refused，说明连接没发出去——这时防火墙（系统级 + 云平台安全组）是第一嫌疑对象 - 注意：即使主库
bind-address = 0.0.0.0且服务正常，防火墙仍可单方面丢包；反过来，防火墙开了但skip-networking = ON，端口照样不监听
检查主库防火墙和云安全组
很多团队只关了本地防火墙，却忘了云服务器还有独立的安全组策略。两者缺一不可，且规则必须显式放行 TCP 3306 入站：
- Linux 主库（firewalld）：
sudo firewall-cmd --permanent --add-port=3306/tcp --zone=public，然后sudo firewall-cmd --reload - Linux 主库（ufw）：
sudo ufw allow 3306/tcp（只写allow 3306默认是 deny，无效） - 阿里云/腾讯云/AWS：登录控制台 → 安全组 → 入方向规则 → 添加规则：类型 TCP，端口 3306，源 IP 填从库的公网/内网 IP（或
0.0.0.0/0仅限测试） - 验证是否生效：
ss -tuln | grep :3306应显示LISTEN；再从从库telnet测试一次
主库用户没有 REPLICATION SLAVE 权限
即使网络通了，从库仍会报 Last_IO_Error: error connecting to master 或更具体的 Access denied。这不是密码错，而是账号根本没被授权做复制：
- 登录主库执行：
SELECT user, host FROM mysql.user WHERE user = 'repl';（假设你用的是repl用户） - 如果
host是localhost，那它只能本机连——必须是'repl'@''或'repl'@'%' - 正确授权语句：
CREATE USER 'repl'@'%' IDENTIFIED BY 'strongpass'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; FLUSH PRIVILEGES; - 注意：
REPLICATION SLAVE是最小必要权限，不要用ALL PRIVILEGES；%在生产环境有风险，应尽量限定为从库具体 IP
主库未启用 binlog 或 server-id 冲突
从库依赖主库的 binlog 日志同步数据，如果主库压根没开 binlog，或者 server-id 和从库一样，复制链路会在协议层就断掉：
- 检查主库是否开启 binlog：
SHOW VARIABLES LIKE 'log_bin';返回ON才有效；若为OFF，需在[mysqld]段添加log-bin = mysql-bin并重启 - 检查
server-id：SHOW VARIABLES LIKE 'server_id';主从必须唯一，不能都是 1；主库建议设为1，从库设为2、3等 - 修改后必须重启 MySQL（
systemctl restart mysql），仅SET GLOBAL不生效 - binlog 格式推荐
ROW：binlog_format = ROW，兼容性更好，避免某些函数/临时表导致的复制中断
防火墙和用户权限这两块最容易漏查——尤其当主库能被其他客户端连上时，人会下意识认为“网络没问题”，但其实只是那个客户端 IP 恰好被放行了。复制用的账号和普通应用账号是两套逻辑，得单独验。
