典型错误是Last_IO_Error: log event entry exceeded max_allowed_packet，本质是主库生成的binlog event体积超过从库max_allowed_packet接收上限，IO线程断开；须同步调大主从库该参数至相同值，并在[mysqld]段配置后重启服务。
主库 binlog 事件超限导致从库 IO 线程中断
典型错误是 Last_IO_Error: log event entry exceeded max_allowed_packet，本质是主库生成的某个 binlog event（比如一个大事务的完整 SQL 或 LOAD DATA 语句）体积超过了从库 max_allowed_packet 的接收上限，IO 线程直接断开。这不是网络问题，而是协议层拒绝接收——哪怕主库能发，从库不认。
- 必须同时调大主库和从库的
max_allowed_packet，只改主库没用；主库值决定 binlog event 能不能生成，从库值决定能不能解析 - 主从值建议严格一致，至少从库 ≥ 主库；若从库略小（如主 512M、从 256M），遇到刚好卡在边界的大事务仍会失败
- 云数据库（如阿里云 RDS）上，
SET GLOBAL常被禁用，必须走控制台参数模板修改，且修改后需重启节点（非仅重载）
为什么改了 my.cnf 还不生效？看配置段和重启要求
max_allowed_packet 在配置文件中写错段落等于白改。MySQL 启动时只读取 [mysqld] 段的设置用于服务端，而 [client] 或 [mysql] 段对复制线程无效——因为复制 IO 线程是 mysqld 自身进程，不是外部客户端。
- 主库和从库都必须在
[mysqld]下设置：max_allowed_packet = 512M - 改完必须执行
systemctl restart mysql（或对应服务名），mysqladmin reload或SIGHUP不触发该参数重载 - 验证是否生效：登录对应实例执行
SELECT @@max_allowed_packet;，注意是全局值，不是会话值
LOAD DATA INFILE 同步失败的特殊处理
如果同步中断源于 LOAD DATA INFILE 语句，光调大 max_allowed_packet 可能治标不治本。这类语句在 binlog 中以原始文件内容形式记录（当 binlog_format=STATEMENT 时）或转换为等效 INSERT（ROW 格式），但字段内含未转义换行符会导致单行长度暴增。
- 先检查源数据文件单行最大宽度：
head -n 1000 source.csv | awk '{print length}' | sort -nr | head -1 - 确认从库
local_infile是否开启：SELECT @@local_infile;，若为OFF则LOAD DATA无法执行（即使包大小够） - 云环境通常禁用
local_infile，此时应改用mysqlimport工具或拆成批量INSERT，避免依赖该语句同步
设成 2G 仍报错？内存与协议开销不是心理作用
max_allowed_packet = 2G 并不意味着你能安全导入 2GB 的 SQL 文件。MySQL 协议在传输时有额外封装（如包头、校验、分片标记），实际可用净荷比设定值小约 4–8KB；更关键的是，该值受限于 net_buffer_length 和物理内存——若服务器剩余内存不足 2.1G，mysqld 启动时可能静默降级到默认值（如 4M），且不报错。
- 启动时加
--verbose --help查看实际加载的参数值，确认没有被覆盖或截断 - 观察
SHOW VARIABLES LIKE 'net_buffer_length';，它影响初始缓冲区分配，建议设为max_allowed_packet的 1/16 左右（如后者 512M，则前者设 32M） - 真正的大文件迁移，优先考虑分卷导出（
mysqldump --skip-extended-insert --net-buffer-length=1M）+ 分批导入，比硬扛单个超大包更稳
