主库binlog文件被purge导致1236错误，核心原因是从库请求的binlog文件在主库中已不存在；验证方式为比对show binary logs与relay_master_log_file；优先重建从库或通过备份+mysqlbinlog补齐gtid，严禁硬调position以防丢数据。
主库 binlog 文件缺失导致 1236 错误
错误信息里出现 could not find next log 或 Could not find first log file name in binary log index file，基本能确定是主库上从库正在请求的 binlog 文件已被删除——不是磁盘损坏，而是被 purge 掉了。常见于 expire_logs_days 设置过小、手动执行 PURGE BINARY LOGS、或主库异常重启后 binlog 索引错乱。
验证方式：登录主库，运行 SHOW BINARY LOGS;，比对从库 Relay_Master_Log_File（如 mysql-bin.000288）是否还在列表中。不在，就是缺失。
- 若只是索引文件（
mysql-bin.index）损坏或内容不一致，可尝试重建：停主库 mysqld → 手动编辑mysql-bin.index，只保留当前存在的 binlog 文件名（每行一个，带完整路径），再启动 mysqld - 但更大概率是文件真没了。此时不能硬改 position 继续拉日志，否则会跳过事务、丢数据
- 优先考虑用备份 +
mysqlbinlog --include-gtids补齐缺失 GTID 区间；若无备份且 GTID 模式启用，需合并主库gtid_executed和从库已执行的 GTID 集，再设gtid_purged
GTID 模式下 gtid_purged 设置错误
报错含 MASTER_AUTO_POSITION = 1 和 purged binary logs containing GTIDs that the slave requires，说明从库声称自己需要某段 GTID（比如 uuid:1-100），但主库的 gtid_purged 已包含该段，且对应 binlog 被删。关键点在于：gtid_purged 必须严格等于「主库已删日志所覆盖的 GTID 集合」，且从库 gtid_executed 中的 GTID 不能被它覆盖掉。
操作前务必确认两件事：
- 在主库查：
SELECT @@global.gtid_executed, @@global.gtid_purged;—— 注意gtid_purged是子集，gtid_executed是全集 - 在从库查：
SELECT @@global.gtid_executed;—— 这个值必须被最终设置的gtid_purged完全覆盖（即并集），否则START SLAVE会拒绝启动 - 设置前必须先
RESET MASTER;清空从库gtid_executed（否则SET GLOBAL gtid_purged = ...报错）；但注意：这会清空所有已执行事务记录，仅适用于新搭建或可接受重放的场景
max_allowed_packet 不匹配引发的 1236
错误提示含 log event entry exceeded max_allowed_packet，本质是主库产生的 binlog event 太大（如大事务、LOAD DATA），而从库的 max_allowed_packet 小于该 event 尺寸，导致 IO 线程接收失败。5.6+ 版本还有 slave_max_allowed_packet_size 参数，它优先级高于 max_allowed_packet，专用于复制通道。
排查与修复要点：
- 主从库分别查：
SELECT @@max_allowed_packet, @@slave_max_allowed_packet_size; - 从库上执行：
SET GLOBAL max_allowed_packet = 1073741824;（1G），同时设slave_max_allowed_packet_size = 1073741824（若存在该变量） - 注意：该参数是 session 级还是 global 级？
slave_max_allowed_packet_size是 global-only，且 MySQL 8.0.29+ 才支持；老版本只能靠调大max_allowed_packet - 改完必须
STOP SLAVE; START SLAVE;，仅 reload 配置不生效
物理备份恢复后配置主从报 1236
用 xtrabackup 或 dd 恢复从库后直接配主从，极易触发 1236。因为备份时刻的 gtid_executed 被固化在 xtrabackup_binlog_info 里，但恢复后若没正确注入到 gtid_purged，从库就会向主库索要“自己还没执行过”的 GTID，而主库早已删掉对应日志。
标准动作链（缺一不可）：
- 恢复完成后，先
SET GLOBAL gtid_purged = 'xxx';—— 值来自备份文件中的gtid_executed（不是空字符串，也不是主库当前值） - 紧接着
RESET MASTER;—— 强制清空从库本地gtid_executed，避免与刚设的gtid_purged冲突 -
CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1;—— 此时从库才真正“声明”自己只需要后续 GTID - 切记：不要在
RESET MASTER前执行START SLAVE，否则从库会尝试执行空gtid_executed下的事务，大概率报 1236
最易忽略的是：物理备份恢复后，gtid_purged 必须显式设置，且必须与备份时刻的 gtid_executed 严格一致；任何想“跳过设置、直接 start slave”的侥幸，都会卡在 1236。
