source_log_pos停滞表明io线程未拉取新binlog，需结合last_io_error、错误日志、netstat连接状态、密码过期及主库binlog保留策略综合排查，而非仅依赖replica_io_running: yes。
Source_Log_Pos卡在某个值不动，说明IO线程没推进
从库的 Source_Log_Pos（旧版叫 Read_Master_Log_Pos）长期不变化，最直接的信号是：从库的 IO 线程没在读取主库新产生的 binlog。它不是“同步慢”，而是“根本没动”。常见现象是 Replica_IO_Running: Yes 但 Source_Log_Pos 停滞，Seconds_Behind_Master 持续增大。
检查 IO 线程是否真在运行，别被状态骗了
MySQL 的 SHOW REPLICA STATUS\G 显示 Replica_IO_Running: Yes 并不等于 IO 线程健康。它可能卡在重连、认证失败或网络阻塞中，表面“运行中”，实际已断连但未报错。
- 看
Last_IO_Error字段——哪怕为空，也要执行SELECT @@global.slave_net_timeout;确认超时时间是否过大（默认 60 秒，太长会掩盖连接异常） - 查 MySQL 错误日志（通常是
/var/log/mysql/error.log或mysqld.err），搜索error reconnecting to master或SSL error类关键词 - 用
netstat -tnp | grep :3306在从库上确认是否有到主库 IP:3306 的 ESTABLISHED 连接；没有就说明根本连不上
密码过期是 MySQL 8.0 最隐蔽的卡点
MySQL 8.0 默认启用密码过期策略，一旦主库上的复制用户（如 'repuser'@'%'）密码过期，从库 IO 线程就会静默重连失败，Source_Log_Pos 死锁不动，且 Last_IO_Error 可能只显示模糊提示（如 Your password has expired）。
- 在主库执行
SELECT user, host, password_expired FROM mysql.user WHERE user = 'repuser';确认是否为Y - 立即修复：
ALTER USER 'repuser'@'%' IDENTIFIED BY 'xxx' PASSWORD EXPIRE NEVER; - 如果从库配置里用的是旧密码，且主库改了新密码，还需在从库执行：
STOP REPLICA; CHANGE REPLICATION SOURCE TO SOURCE_PASSWORD = 'xxx'; START REPLICA;
Binlog 文件被主库自动清理，IO 线程无路可读
主库的 binlog_expire_logs_seconds（或老参数 expire_logs_days）设得太小，导致从库还没来得及拉取的 binlog 被主库 purge 掉。此时 IO 线程会卡住，并报错 Could not find first log file name in binary log index file 或类似 Client requested master to start replication from position > file size。
- 在主库查当前最小 binlog：
SHOW BINARY LOGS;，对比从库Source_Log_File是否还在列表中 - 临时补救：在主库执行
FLUSH LOGS;生成新 binlog，再检查Source_Log_File是否已自动切换；若仍缺失，必须重做从库（备份 +--master-data=2） - 长期方案：主库设
binlog_expire_logs_seconds = 2592000（30 天），并监控SHOW REPLICA STATUS\G中的Retrieved_Gtid_Set或Source_Log_File是否持续落后
Source_Log_Pos 的，往往不是配置写错了，而是 IO 线程在后台无声失败——比如密码过期、SSL 握手失败、防火墙拦截了 3306 回包、甚至主库磁盘满导致 binlog 写失败后 dump 线程退出。务必先盯死错误日志和网络连通性，别只刷 SHOW REPLICA STATUS。
