slave_io_running: no 时应先检查主从网络连通性、主库binlog开启状态、复制用户权限及ssl配置，再验证master.info等元数据是否需重置。
查 SHOW SLAVE STATUS 里关键字段的含义
看到 Slave_IO_Running: No，第一反应不是重启复制，而是看它卡在哪一步。重点盯住三个字段：Master_Host、Master_Port、Master_User 是否和主库实际配置一致；再看 Last_IO_Error——这是最直接的线索，比如常见报错 error connecting to master 'repl@10.0.1.5:3306' 就说明网络或认证失败。
注意：Seconds_Behind_Master 此时通常为 NULL，不代表延迟，只代表 IO 线程根本没跑起来。
验证从库能否连上主库的 mysql 端口
别跳过这步。用从库机器执行：telnet 10.0.1.5 3306 或 nc -zv 10.0.1.5 3306。不通？可能是防火墙、安全组、主库 bind_address 配置为 127.0.0.1 导致监听不到外网。
- 主库
my.cnf必须有bind_address = 0.0.0.0或具体内网 IP（不能是127.0.0.1） - 主库用户
repl的 host 要允许从库 IP 连接，比如'repl'@'10.0.1.6'，而不是'repl'@'localhost' - 如果主库在 Docker 或 Kubernetes 里，确认端口是否正确映射，宿主机能否访问该端口
检查主库 binlog 和复制用户权限
Slave_IO_Running: No 多数时候不是配置写错了，而是主库压根没开 binlog，或者用户没给 REPLICATION SLAVE 权限。
- 主库执行
SHOW VARIABLES LIKE 'log_bin';，返回OFF就得改my.cnf加log-bin = mysql-bin并重启 - 主库检查用户权限：
SHOW GRANTS FOR 'repl'@'10.0.1.6';，缺REPLICATION SLAVE就补：GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.0.1.6'; FLUSH PRIVILEGES; - 如果主库开了
require_secure_transport=ON，而从库没配 SSL，也会静默拒绝连接——此时Last_IO_Error可能只显示error connecting，但不提 SSL
重试 start slave 前先 reset slave 的边界条件
改完主库配置或权限后，别急着 START SLAVE。如果之前尝试过多次失败，从库可能残留了错误的 master.info 或 relay log 位置，导致新连接仍沿用旧参数。
- 先执行
STOP SLAVE; - 再执行
RESET SLAVE;（注意：这会清空所有复制元数据，包括MASTER_HOST等——所以你要确保 CHANGE MASTER TO 的语句已经准备好） - 然后重新
CHANGE MASTER TO ...，再START SLAVE; - 如果只是改了主库密码，可以用
CHANGE MASTER TO MASTER_PASSWORD='xxx';，不用全量重配
最容易被忽略的是：RESET SLAVE 后必须重新 CHANGE MASTER TO，否则 START SLAVE 会报 Error 2003: Can't connect to MySQL server，因为所有连接参数都空了。
