报错“position超出范围”本质是主库binlog文件已被清理，从库仍尝试读取已不存在的master_log_file和read_master_log_pos；需先通过show binary logs和show master status确认主库当前可用binlog起点，再用change master to重定位至真实存在的文件与位置，或重建从库。
为什么CHANGE MASTER TO报错“Position超出范围”
这不是从库配置写错了，而是主库的binlog文件已被清理，但从库还在尝试读取一个早已不存在的Master_Log_File和Read_Master_Log_Pos。典型错误是Got fatal error 1236 from master或Could not find first log file name in binary log index file。根本原因是expire_logs_days设置过短、主库重启后binlog轮转、或人为PURGE BINARY LOGS——而从库还没来得及消费完。
确认主库当前可用的binlog位置
先别急着改从库，去主库查真实状态：
- 执行
SHOW BINARY LOGS;，看最老的binlog文件名（比如binlog.000105）和文件大小 - 执行
SHOW MASTER STATUS;，记下当前File（如binlog.000108）和Position（如198） - 对比从库
SHOW SLAVE STATUS\G里的Master_Log_File和Read_Master_Log_Pos：如果它指向binlog.000104这种已不在SHOW BINARY LOGS列表里的文件，就坐实了“位置失效”
重置同步起点的两种安全方式
不能硬填一个“看起来合理”的position，必须对齐主库真实可读的起点：
- 若从库数据仍可用且差异不大：用
STOP SLAVE;→CHANGE MASTER TO MASTER_LOG_FILE='binlog.000105', MASTER_LOG_POS=154;（取SHOW BINARY LOGS里最老文件的起始pos，通常是154）→START SLAVE; - 若从库已严重滞后或不确定一致性：直接走全量重建。在主库用
mysqldump --all-databases --single-transaction --master-data=2导出，该参数会在dump头部写入精确的CHANGE MASTER TO语句，导入从库后直接复用即可 - 严禁用
SET GLOBAL sql_slave_skip_counter = N试图跳过缺失日志——它只跳relay log里的事务，对“找不到binlog文件”完全无效
避免下次再踩坑的关键配置
光修一次不够，得堵住源头：
- 主库调大
expire_logs_days（建议至少7天），并定期检查SHOW BINARY LOGS;输出是否持续增长 - 从库开启
relay_log_recovery=ON（需重启生效），防止崩溃后relay log损坏导致位点错乱 - 监控项必须包含：
Seconds_Behind_Master突变为NULL、Slave_IO_Running变No、以及主库Binlog_space_usage趋势
真正麻烦的不是修复动作本身，而是你得判断：这个“超出范围”到底是临时网络抖动导致位点丢失，还是主库已被人为清过日志——前者可微调，后者必须承认数据链已断，该重建就得重建。
