主从复制因max_allowed_packet中断的核心是主从值必须严格一致且均在[mysqld]段配置并重启生效；若不一致，从库IO线程报错1236或“log event entry exceeded max_allowed_packet”，需用SELECT @@global.max_allowed_packet确认真实服务端值，同步调整主从配置及客户端工具参数。
主从复制因 max_allowed_packet 过小中断，核心问题不是“调大就行”，而是主库和从库的值必须一致、且都生效在服务端全局配置上；只改一端、只改客户端、或没重启，都会白忙活。
怎么看是不是这个参数惹的祸
从库执行 SHOW SLAVE STATUS\G，重点看 Last_IO_Error 字段：
- 出现
log event entry exceeded max_allowed_packet或错误码1236，基本锁定 - 出现
Got a packet bigger than 'max_allowed_packet' bytes，说明是网络包被拒，但需进一步区分主库还是从库限制触发 - 别信
SHOW VARIABLES LIKE 'max_allowed_packet'——它返回会话值，可能被连接池覆盖；必须执行SELECT @@global.max_allowed_packet;查真实服务端值（单位字节） - 对比主库和从库该值：若从库是 4194304（4MB）、主库是 67108864（64MB），就是从库太小；若主库也是 4194304，那得先改主库——大事务根本进不了 binlog
怎么改才真正生效
max_allowed_packet 是启动时加载的只读参数，不支持动态 SET 全局持久化。改错位置、单位、或不重启，等于没改：
- 必须写在配置文件的
[mysqld]段内，例如：max_allowed_packet = 512M（注意：大写M，不能是MB、m或带空格） - 写在
[client]、[mysql]或无段落处，MySQL 启动时直接忽略 - 改完必须完整重启服务：
systemctl restart mysqld（mysqladmin reload或SIGHUP不重载该参数） - 云数据库（如阿里云 RDS）不支持
SET GLOBAL，需在控制台修改参数模板，并重启节点（不是“重载”） - 验证是否生效：重启后连上去执行
SELECT @@global.max_allowed_packet;，确认输出值与配置一致
为什么只调高从库还不够
主库 max_allowed_packet 设太小，会导致两类隐性失败，从库再大也救不回来：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 大
INSERT或LOAD DATA INFILE在主库执行时就被截断，binlog 记录的是残缺事件，从库解析必然失败 - 主库
binlog_format = ROW时，一条更新可能携带数百 KB 行镜像数据；若主库限制为 4MB，这类事件直接被拒绝写入 binlog，从库同步断在空档 - 某些 MySQL 版本（如 5.7.20 前）处理超大 binlog event 有 bug，报错指向从库，根因却在主库配置
- 主从必须设相同值，推荐统一为
512M或1G（即1073741824）；设超过 1G 容易触发内存分配异常，不建议盲目拉到 2G
修复已中断的复制链路
光改配置重启不够，IO 线程已退出，需手动恢复同步点：
- 先停复制：
STOP SLAVE; - 查主库当前位点：
SHOW MASTER STATUS; - 用
mysqlbinlog检查报错附近事件是否损坏，例如：mysqlbinlog /var/lib/mysql/mysql-bin.000032 | head -n 50 - 若确认事件完整，可跳过错误（谨慎）：
SET GLOBAL sql_slave_skip_counter = 1; START SLAVE; - 更稳妥做法是重新初始化从库：备份主库并指定
--master-data=2，导入从库后CHANGE MASTER TO指向对应位点 - 注意：
slave_max_allowed_packet_size（MySQL 5.6+）可单独设为大于max_allowed_packet，作为从库接收层兜底，但主库仍需匹配
最常被忽略的点：主库和从库的 max_allowed_packet 必须数值相等、单位一致、配置段正确、且都经过完整重启；任何一环掉链，复制就卡在 1236。
