1236错误主因是MySQL升级导致GTID状态不一致、binlog格式变更或server-id重置；须先确认GTID模式（SELECT @@global.gtid_mode）、Master_Auto_Position值、server-id唯一性、binlog_format及max_allowed_packet一致性，再按模式精准修复。
MySQL升级后出现1236错误，基本可以确定不是网络或权限问题，而是升级过程破坏了复制链路的连续性——最常见的是GTID状态不一致、binlog格式变更、或server-id被重置。必须按模式区分处理，混用修复方式会直接失败。
确认是否启用了GTID模式
升级后MySQL默认行为可能变化（如5.7→8.0默认开启GTID），但旧从库仍按传统file/pos模式运行，导致IO线程请求方式冲突。
- 在从库执行
SELECT @@global.gtid_mode;，返回ON说明已启用GTID；返回OFF则为传统模式 - 检查从库
SHOW SLAVE STATUS\G中的Master_Auto_Position字段：值为1表示走GTID，0表示走file/pos - 若主库GTID已开，但从库
Master_Auto_Position=0，强制切换前必须先STOP SLAVE，再CHANGE MASTER TO MASTER_AUTO_POSITION = 1，否则报1236
检查server-id是否被覆盖或重复
升级过程中my.cnf可能被模板重写，server-id丢失或设为默认值（如1），导致主从拒绝连接，错误提示却指向日志位置——这是最隐蔽的坑。
- 在主库和从库分别执行
SELECT @@global.server_id;，确认值为非零整数且全局唯一 - 检查配置文件
[mysqld]段下是否存在server-id，注意不要写成server_id（下划线无效） - 升级后若发现
server-id变成0或重复，修改配置后必须重启MySQL，仅SET GLOBAL不生效
验证binlog格式与过期策略是否兼容
MySQL 8.0+默认binlog_format=ROW，而老版本从库若仍用MIXED或STATEMENT，大事务解析失败会触发1236；同时binlog_expire_logs_seconds（8.0.28+）可能替代了expire_logs_days，旧监控脚本未识别新参数，导致日志被误删。
- 主从两端均执行
SELECT @@global.binlog_format;，确保一致；不一致时需停复制后统一修改 - 主库执行
SHOW VARIABLES LIKE 'expire_logs_days';和SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';，两个参数都得查——8.0.28+优先使用后者，若只调大expire_logs_days无效 - 升级后首次启动，主库可能因
gtid_purged为空自动清空，此时从库若依赖旧GTID，必须手动补全：SET GLOBAL gtid_purged = '...';（内容来自主库gtid_executed与从库gtid_executed合并去重）
排查max_allowed_packet是否因升级重置
升级包常带默认配置覆盖，max_allowed_packet被设回4MB，而主库产生大事务binlog event时，从库接收失败直接报1236，错误信息里明确含log event entry exceeded max_allowed_packet。
- 主从两端执行
SELECT @@global.max_allowed_packet;，确保数值一致（建议至少1GB） - 若从库值偏小，执行
SET GLOBAL max_allowed_packet = 1073741824;，再STOP SLAVE; START SLAVE; - MySQL 5.6+可用
slave_max_allowed_packet_size单独调大从库接收上限，避免影响其他连接
升级后的1236错误，核心陷阱在于“表面是日志缺失，实际是元数据错位”。GTID状态、server-id、binlog格式这三项必须严格对齐，任何一项被升级脚本悄悄改掉，都会让复制在无声中断裂。动手前务必先比对主从的gtid_mode、server_id、binlog_format和max_allowed_packet——四者缺一不可。
