错误1236源于主库缺失从库所需binlog文件或gtid段，非网络权限问题；需据file/pos或gtid模式分别处理：先用show binary logs确认文件是否存在，再查expire_logs_days等参数；非gtid下可用change master to重设位点，gtid下须先reset master再精准设置gtid_purged，且mysql 8.0.23+在未人工干预时可自动重发现。
1236 错误不是网络或权限问题，而是主库确实没了从库要读的 binlog 文件或 GTID 段——修复方式取决于你用的是传统 file/pos 还是 GTID 模式，不能混用。
确认主库是否已删掉目标 binlog 文件
先看错误信息里明确提到的文件名，比如 Could not find first log file name 'mysql-bin.000022'。登录主库执行：SHOW BINARY LOGS;
如果列表里没有 mysql-bin.000022，说明已被 purge；再查：SELECT @@global.expire_logs_days, @@global.binlog_expire_logs_seconds;
两个参数都可能触发自动清理，别只盯一个。
若文件名存在但 ls -l /path/to/mysql-bin.000022 报 no such file，就是磁盘损坏或路径配置错，不是 1236 的典型场景。
非 GTID 模式下快速重设位点（仅当主库还有可用 binlog）
适用前提：主库 SHOW BINARY LOGS 至少有一个文件存在，且你接受跳过中间变更（如日志表、缓存类数据）。
操作步骤：
- 在从库执行
STOP SLAVE; - 在主库执行
SHOW MASTER STATUS;，记下当前File（如mysql-bin.000043）和Position（通常为4） - 在从库执行：
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000043', MASTER_LOG_POS=4; - 再
START SLAVE;
RESET SLAVE 会清空 master.info 和 relay log，反而增加风险；CHANGE MASTER TO 是精准修正，不丢上下文。
GTID 模式下设置 gtid_purged 的硬约束
常见卡点：SET GLOBAL gtid_purged = 'xxx' 直接报错 “Variable 'gtid_purged' can only be set when @@global.gtid_executed is empty”。
必须分两步：
- 先在从库执行
RESET MASTER;（这会清空本机gtid_executed，慎用！） - 再执行
SET GLOBAL gtid_purged = 'a1b2c3e4-5678-90ab-cdef-123456789012:1-100,a2b2c3e4-5678-90ab-cdef-123456789013:1-50';，这个值必须包含：主库的gtid_purged+ 从库原gtid_executed中属于主库 UUID 的部分
gtid_purged，则从库会试图重拉已执行事务，大概率失败。
真正容易被忽略的点
MySQL 8.0.23+ 的 IO 线程在报 1236 后会主动“重发现”最新 binlog，但前提是没人工干预过 —— 一旦你执行过 STOP SLAVE，它就不再自动触发。所以看到报错别急着 stop/start，先 SHOW SLAVE STATUS\G 看 Last_IO_Error 是否刚出现、Seconds_Behind_Master 是否还在涨；有时等 30 秒，它自己就续上了。另外，sql_slave_skip_counter 在 GTID 或 RBR 下完全无效，强行用只会让同步彻底乱掉。
