Fix: Got a packet bigger than 'max_allowed_packet' bytes

This error means a single MySQL protocol packet (one SQL statement, one row of a result, or one binlog event) exceeded the max_allowed_packet limit, so it was refused. It typically surfaces the day someone inserts a large blob, imports a dump full of multi row inserts, or a table with a LONGTEXT column accumulates a genuinely big value. The trap is that the limit exists independently on the server and in every client and replication thread, and the effective limit for a session is whichever side is smaller.

ERROR 1153 (08S01): Got a packet bigger than 'max_allowed_packet' bytes

What this error means

The MySQL client/server protocol frames traffic into packets, and max_allowed_packet caps the size of any single packet: an entire SQL statement traveling to the server, a single row traveling back, or a binlog event flowing to a replica. The default has grown over versions (64M in MySQL 8.0) but older configs and clients often pin it far lower, and 4M or 16M values still roam production. When a packet exceeds the receiver’s limit, the receiver rejects it; depending on which side and when, you see error 1153, error 2006 (server has gone away) on the client, or a replication thread stopping.

Common causes

• Inserting or updating a large BLOB, LONGTEXT, or JSON value (file uploads, serialized payloads, base64 images) bigger than the limit.
• Restoring a mysqldump file whose multi row INSERT statements exceed the client or server limit.
• A server limit raised in my.cnf while clients, connectors, or mysqldump still enforce their own smaller default.
• Replication breaking because a replica’s max_allowed_packet is lower than the source’s, so a large binlog event cannot be delivered.
• Huge IN (...) lists or programmatically generated statements that grow with data volume until one day they cross the line.
• An application that stores files in the database growing its typical object size past the original design assumption.

How to fix it

STABILIZE first. Raise the server limit dynamically (no restart needed); new connections pick it up immediately, which usually unblocks the failing job.

1. DIAGNOSE: check the current server limit and compare it to the size of what you tried to send.

SHOW VARIABLES LIKE 'max_allowed_packet';

If a specific row is the trigger, measure the biggest values in the column involved:

SELECT MAX(LENGTH(payload)) AS biggest_bytes FROM documents;

2. FIX the server limit at runtime, then persist it so a restart does not silently revert it.

SET GLOBAL max_allowed_packet = 268435456;

# /etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld]
max_allowed_packet = 256M

Note that SET GLOBAL affects new connections only; existing sessions keep their old value, so restart the application pool or reconnect.

3. FIX the client side, because the client enforces its own ceiling. For the CLI tools:

mysql --max-allowed-packet=256M -h db.internal -u app -p appdb < dump.sql
mysqldump --max-allowed-packet=256M -h db.internal -u app -p appdb > dump.sql

For connectors, set the equivalent option (for example maxAllowedPacket in JDBC, max_allowed_packet in the client section of an option file) to match the server.

4. FIX replication if a replica stopped: raise the limit on the replica to at least the source’s value, then restart replication.

SET GLOBAL max_allowed_packet = 268435456;
STOP REPLICA; START REPLICA;
SHOW REPLICA STATUS\G

5. DIAGNOSE whether the workload itself is the problem. If a single value approaches hundreds of megabytes, SQL is the wrong transport: store the object in object storage (S3 or equivalent) and keep only the key and metadata in MySQL, or chunk the value across rows.

How to prevent it

• Set max_allowed_packet explicitly in configuration management, identical across source, replicas, and clients, so no environment runs a surprise default.
• Keep large binary objects out of the database; store a reference and put the bytes in object storage.
• Cap upload and payload sizes in the application at a value safely below the packet limit, so users hit a friendly error instead of a database one.
• Use the same packet option on mysqldump and restore commands in your backup scripts, and test restores routinely.
• Alert when the largest values in blob columns trend toward the limit, which turns a future outage into a planning item.
• Avoid unbounded generated SQL like giant IN lists; batch them.

When to call a senior engineer

Call for help when raising the limit keeps chasing ever larger payloads, when replication repeatedly breaks on oversized events, or when a schema that stores files in table rows is starting to strain backups, memory, and restore times. Erzon engineers can right size the limits across your fleet, migrate blob storage out of MySQL without downtime, and leave your dump and restore pipeline able to handle your largest real rows.