ERROR 1236 根本原因是复制断点不可达，即从库请求的GTID或binlog位置在主库已缺失；常见于主库binlog被purge、GTID集不匹配、max_allowed_packet不一致或首次搭建时gtid_purged设置不全。
ERROR 1236 在 MySQL 8.0 开启 GTID 后主从同步中出现，根本原因是复制链路断点不可达——从库请求的 GTID 或 binlog 位置，主库已无法提供。这不是网络或权限问题，而是数据“源头缺失”。
常见触发场景有两类：一是主库 binlog 被清理（PURGE BINARY LOGS 或过期策略），二是主从 GTID 集不匹配（尤其首次搭建或模式切换时）。错误信息里那句 “The slave is connecting using MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires” 就是典型信号。
主库 binlog 已被 purge，但从库还在要
这是最常踩的坑。从库通过 Retrieved_Gtid_Set 告诉主库：“我缺 uuid:1-100”，主库查了下自己的 gtid_purged，发现这部分 GTID 对应的 binlog 早被删了。
- 执行
SHOW BINARY LOGS;看主库当前 binlog 列表，对比错误日志里提到的文件名（如mysql-bin.000123）是否还在 - 检查
expire_logs_days和binlog_expire_logs_seconds（MySQL 8.0.28+）两个参数，别只看一个 - 用
ls -l /path/to/binlog/mysql-bin.000123确认文件物理存在——有时 index 里有，磁盘上却没了（比如磁盘损坏、路径配置错） - 如果 binlog 确实没了，且没有备份，就只能重建从库；否则可临时调大保留周期：
SET GLOBAL binlog_expire_logs_seconds = 604800;
从库 gtid_purged 设置不完整或时机错误
很多人以为只要把主库的 gtid_purged 值 SET 过去就完事，结果 START SLAVE 直接失败，甚至触发全量重拉。
-
SET GLOBAL gtid_purged只能在gtid_executed为空时执行，否则报错；清空方式是RESET MASTER，但它会清掉本机所有 GTID 记录，慎用 - 正确做法是：先
STOP SLAVE，再用SELECT @@global.gtid_executed;拿到从库自己已执行的 GTID，和主库的gtid_purged合并去重（不是简单拼接） - 例如主库
gtid_purged = 'A:1-10,B:1-5'，从库gtid_executed = 'A:1-8,C:1-3'，合并后应为'A:1-10,B:1-5,C:1-3' - 设置前务必确认从库没写入过数据，否则
C:1-3这类本地 GTID 会导致主从冲突
主从 max_allowed_packet 不一致导致 event 传输失败
这个错误也报 ERROR 1236，但原因完全不同：主库产生了一个超大 binlog event（比如大事务、LOAD DATA），从库接收时超出自身 max_allowed_packet 限制。
- 错误信息里带
log event entry exceeded max_allowed_packet就是它 - 检查主从该参数是否一致：
SELECT @@max_allowed_packet; - 从库需 ≥ 主库值，建议统一设为
1073741824（1G），并写入配置文件避免重启丢失 - MySQL 5.6+ 还有
slave_max_allowed_packet_size参数，它优先级高于max_allowed_packet，可单独调大
首次搭建或从传统模式切 GTID 时漏设主库全部 gtid_executed
MySQL 8.0 要求：从库 gtid_purged 必须包含主库 gtid_executed 的全部内容。漏掉任意一个 UUID 区间，就会报 Last_IO_Errno: 13114（本质仍是 1236）。
- 在主库执行
SELECT @@global.gtid_executed;，拿到完整字符串 - 从库必须执行
RESET MASTER+SET GLOBAL gtid_purged = '...';，不能跳过RESET MASTER - 如果从库之前已有数据，且
gtid_executed非空，说明它不是干净实例——这种情况下不应直接设gtid_purged，而应考虑用 xtrabackup 全量重建
GTID 复制的“一致性”要求很硬，gtid_purged 的值一旦设错，后续很难回退。最稳妥的做法是：首次部署前确认主库 binlog 未被 purge，且从库为全新实例；已有从库出问题时，优先比对 gtid_executed 和 gtid_purged 的差集，而不是盲目 reset。
