1236错误本质是主库找不到从库请求的binlog文件或GTID位置，非日志损坏而是位点失配；需按复制模式选择修复方式：GTID模式下应SET GLOBAL gtid_purged=主库Executed_Gtid_Set，禁用RESET MASTER；传统模式可STOP SLAVE后CHANGE MASTER TO指定现存binlog文件及pos=4再START SLAVE。
1236 错误本质是主库找不到从库要读的 binlog 文件或位置，不是“坏了”，而是“断连后对不上号了”——重置位点或刷新 master 状态能快速恢复，但必须匹配当前复制模式（GTID 还是传统 file/pos）。
用 RESET MASTER 前必须确认 GTID 模式是否启用
在 GTID 模式下执行 RESET MASTER 会清空 gtid_executed 和 gtid_purged，但也会让 gtid_purged 变为空，导致后续 START SLAVE 因缺少必要 GTID 而报错 “master has purged binary logs containing GTIDs that the slave requires”。
- 只在非 GTID 模式（即靠
MASTER_LOG_FILE/MASTER_LOG_POS同步）下，RESET MASTER才安全且常用 - GTID 模式下，真正该操作的是
SET GLOBAL gtid_purged = '...'，而非RESET MASTER - 若误在 GTID 模式下执行了
RESET MASTER，必须立刻用SHOW MASTER STATUS查出当前Executed_Gtid_Set，再手动补回gtid_purged
传统 file/pos 模式下重设位点的关键三步
当错误信息含 Client requested master to start replication from impossible position 或 Could not find first log file name in binary log index file，说明从库记录的 binlog 文件名已在主库上不存在，或 pos 超出文件末尾。
- 先在主库执行
SHOW BINARY LOGS，确认现存最小 binlog 文件名（如mysql-bin.000291） - 再在从库执行
STOP SLAVE，然后CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000291', MASTER_LOG_POS=4（pos=4 是每个 binlog 文件的固定起始位置） - 最后
START SLAVE；如果仍报 1236，大概率是主库已删掉该文件，此时必须跳过旧同步点、重建从库或使用备份+binlog 补齐
GTID 模式下设置 gtid_purged 的两个硬约束
从库执行 SET GLOBAL gtid_purged = '...' 报错 “Variable 'gtid_purged' can only be set when @@global.gtid_executed is empty” 是最常卡住的地方。
- 必须先执行
RESET MASTER清空gtid_executed（注意：这会丢弃本机已执行的所有 GTID 记录） -
gtid_purged的值不是随便填的，它应为：主库的 gtid_purged∪从库原 gtid_executed 中属于主库 UUID 的部分 - 漏掉从库自己已执行的 GTID，会导致从库重复拉取并执行已存在事务，引发主键冲突或数据不一致
真正容易被忽略的是：1236 错误本身不区分“可修复”和“不可逆丢失”，当主库 binlog_expire_logs_seconds 过短、或 DBA 手动 PURGE BINARY LOGS 后又未及时同步从库，位点就真的没了——此时重设位点只是掩盖问题，数据一致性已无法保障。
