主库必须开启binlog并正确配置：log_bin=mysql-bin且server_id为非0唯一整数，重启后通过select @@log_bin和show variables确认生效；同时确保从库网络可达、复制用户权限正确、change master to参数与主库show master status完全一致，并检查last_io_error定位具体错误。
检查主库是否开启binlog并配置正确
如果主库没开binlog，从库根本拉不到日志，Slave_IO_Running 必然为 No。先确认主库 my.cnf 中有这两项且已生效：
-
log-bin=mysql-bin（路径名需合法，不能是绝对路径带空格或特殊字符） -
server-id=1（必须是非0整数，且全集群唯一）
改完记得重启 MySQL 或执行 SELECT @@log_bin; 确认返回 1；再查 SHOW VARIABLES LIKE 'log_bin'; 和 SHOW VARIABLES LIKE 'server_id';，确保不是只读变量未生效。
验证从库能否连通主库并拥有复制权限
Slave_IO_Running=No 最常见原因是网络或权限问题，IO线程压根没起来。在从库执行：
mysql -h 主库IP -u 复制用户 -p -e "SELECT 1"
如果连不上，先排查防火墙、SELinux、bind-address 是否绑定了 127.0.0.1。连得上但报 Access denied，说明复制用户权限不对，主库需执行：
CREATE USER 'repl'@'从库IP' IDENTIFIED BY 'xxx';GRANT REPLICATION SLAVE ON *.* TO 'repl'@'从库IP';FLUSH PRIVILEGES;
注意：不要用 'repl'@'%'，除非你明确允许任意IP连接，否则容易因反向DNS解析失败导致授权不生效。
检查CHANGE MASTER TO参数是否匹配主库当前状态
如果 MASTER_LOG_FILE 或 MASTER_LOG_POS 指向了不存在的 binlog 文件或过期位置，IO线程会启动失败并静默退出。在主库执行：
SHOW MASTER STATUS;
拿到当前 File 和 Position，再对比从库的 SHOW SLAVE STATUS\G 中的 Master_Host、Master_User、Master_Port 是否一致，尤其注意：
-
Master_Host是 IP 还是域名？DNS 解析是否稳定？建议统一用 IP -
Master_Port默认 3306，如果主库改了端口，这里必须显式指定 -
MASTER_LOG_FILE名字要完全一致（包括大小写），MySQL 对文件名区分大小写
一旦参数有误，直接 STOP SLAVE; 后重新 CHANGE MASTER TO ...;，别试图跳过重置。
查看Last_IO_Error定位具体失败原因
SHOW SLAVE STATUS\G 的 Last_IO_Error 字段才是真相。常见值包括：
-
Connecting to master...：卡在连接阶段 → 查网络和权限 -
Could not find first log file name in binary log index file：MASTER_LOG_FILE文件名错或主库 binlog 被清过 → 重新SHOW MASTER STATUS -
Authentication plugin 'caching_sha2_password' cannot be loaded：MySQL 8.0 默认认证插件不兼容旧客户端 → 主库执行ALTER USER 'repl'@'xxx' IDENTIFIED WITH mysql_native_password BY 'xxx'; -
SSL connection error：启用了 SSL 但没配证书 → 在CHANGE MASTER TO加MASTER_SSL=0或补全 SSL 参数
这个字段不为空时，基本不用猜，照着字面意思修就行。但要注意：有些错误只出现一次，之后变成空字符串，所以发现 Slave_IO_Running=No 后第一时间看它。
真正麻烦的是 Last_IO_Error 为空但状态仍是 No，这种情况往往卡在 DNS 反查或 SELinux 限制，得去查 MySQL 错误日志（mysqld.err），而不是只盯 SHOW SLAVE STATUS。
