1236错误需先根据报错末尾信息判断具体类型：若含“Could not find first log file name”则主库binlog已删除；若含“position > file size”则从库位点超出主库当前binlog长度；若含“log event entry exceeded max_allowed_packet”则主从max_allowed_packet不一致或事务过大；若含“source purged required binary logs + GTID”则GTID模式下主库已清除从库尚未复制的事务。
确认1236错误具体类型，别一上来就重搭
报错 Got fatal error 1236 from master when reading data from binary log 是个“症状集合”，不是单一病因。你得先看完整错误信息末尾那句——它直接告诉你问题在哪：
- 含
Could not find first log file name→ 主库 binlog 文件真没了（最常见） - 含
position > file size→ 从库记的 pos 超出主库当前 binlog 文件实际长度（常因主库异常重启） - 含
log event entry exceeded max_allowed_packet→ 主从max_allowed_packet不一致或事务太大 - 含
source purged required binary logs+ GTID 字符串 → GTID 模式下主库删了从库还没拉的事务
不区分类型就 RESET SLAVE 或 mysqldump 重建，大概率白忙活半天，还可能引入新错。
非 GTID 模式下：用 SHOW BINARY LOGS + CHANGE MASTER TO 快速重连
适用于 MASTER_AUTO_POSITION = 0 或没开 GTID 的老集群。核心思路是：让从库放弃旧坐标，改连主库现存最老 binlog 的起始位置（pos=4）。
- 在主库执行
SHOW BINARY LOGS，找列表里第一个文件名（比如mysql-bin.000317） - 在从库执行：
STOP SLAVE;<br>CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000317', MASTER_LOG_POS=4;<br>START SLAVE;
- 立刻查
SHOW SLAVE STATUS\G：若Slave_IO_Running: Yes且Seconds_Behind_Master开始下降，说明成功；若仍报 1236，说明mysql-bin.000317也被删了，必须走备份重建
注意：MASTER_LOG_POS=4 是每个 binlog 文件的固定 header 起始位，不是随便填的；填错会直接触发 position > file size 类新错。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
GTID 模式下：SET GLOBAL gtid_purged 是唯一安全入口
RESET MASTER 在 GTID 模式下是危险操作，它清空 gtid_executed 但不自动补回 gtid_purged，后续 START SLAVE 必报错。正确路径是手动对齐 gtid_purged：
- 在主库执行
SELECT @@global.gtid_executed, @@global.gtid_purged，记下完整值（如a-b-c:1-100,b-c-d:1-50） - 在从库执行
STOP SLAVE; RESET SLAVE ALL;（ALL确保清掉旧状态） - 在从库执行
RESET MASTER;—— 这步必须做，否则gtid_purged无法设置（报错Variable 'gtid_purged' can only be set when @@global.gtid_executed is empty） - 再执行
SET GLOBAL gtid_purged = 'a-b-c:1-100,b-c-d:1-50';（值必须严格等于主库的gtid_executed） - 最后
CHANGE MASTER TO MASTER_AUTO_POSITION = 1; START SLAVE;
漏掉 RESET MASTER 或填错 gtid_purged 值，IO 线程会卡在 Connecting 状态，日志里反复刷 Cannot replicate because the source purged required binary logs。
跳过错误前先看清楚：sql_slave_skip_counter 在 GTID 下完全失效
很多老文档还在教 SET GLOBAL sql_slave_skip_counter = 1，这招只在 SBR（基于语句）+ 非 GTID 模式下有效。一旦开了 GTID，这个变量被 MySQL 忽略，执行后 SHOW SLAVE STATUS 里的 Exec_Master_Log_Pos 和 Retrieved_Gtid_Set 完全不变，SQL 线程照常报错。
- GTID 模式下跳单条事务，必须用空事务注入：
SET GTID_NEXT = 'a-b-c:101';<br>BEGIN;<br>COMMIT;<br>SET GTID_NEXT = 'AUTOMATIC';
- 但前提是你要从
SHOW SLAVE STATUS\G的Retrieved_Gtid_Set和Executed_Gtid_Set差集里，精准算出缺失的那个 GTID（比如a-b-c:101），填错一个字符，后续同步就彻底乱序 - 生产环境不建议跳过，除非你 100% 确认那条事务可丢（比如测试数据写入从库），因为跳过本身不解决 binlog 缺失问题，只是绕开它
真正容易被忽略的是：所有修复动作都依赖主库 binlog 是否还活着。如果 SHOW BINARY LOGS 返回空，或者 gtid_purged 里那个 UUID 对应的事务范围已超出主库当前 gtid_executed，那就没有“拉起”这回事了——只能重建从库。
