🚨 MySQL Error Guide: 'ERROR 1153 (08S01)' Got a Packet Bigger Than max_allowed_packet

Exact Error Message

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

During a mysqldump restore the same limit appears as a lost connection with a packet hint:

ERROR 2006 (HY000): MySQL server has gone away
Got a packet bigger than 'max_allowed_packet' bytes

What the Error Means

MySQL’s client/server protocol moves data in packets, and a single packet may not exceed max_allowed_packet bytes. When a statement or result row is larger than this limit — a huge INSERT, a multi-megabyte BLOB, a wide multi-row insert, or one enormous line in a dump file — the side receiving it rejects the packet and raises ERROR 1153 with SQLSTATE 08S01 (a communication-link failure). The connection is usually dropped in the process, which is why a restore can also show ERROR 2006.

Crucially, both the client and the server have their own max_allowed_packet setting. The effective ceiling is the smaller of the two for any given direction, so raising it only on the server is often not enough.

Common Causes

• Inserting or updating a BLOB/TEXT/JSON value larger than max_allowed_packet.
• Restoring a mysqldump whose extended-insert lines exceed the limit (common with --extended-insert and large rows).
• Bulk multi-row INSERT ... VALUES (...), (...), ... statements assembled too large by the application.
• A client (mysql, connector, ORM) with a smaller max_allowed_packet than the server.
• Replication applying a large event when the replica’s max_allowed_packet is smaller than the source’s.
• A corrupt or malformed packet making the server interpret a length field as enormous.

How to Reproduce the Error

Set a tiny limit for the session and try to insert a value larger than it:

mysql -e "SET GLOBAL max_allowed_packet = 1048576;"

CREATE TABLE blobs (id INT, data LONGBLOB);
INSERT INTO blobs VALUES (1, REPEAT('x', 2000000));

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

The 2 MB value exceeds the 1 MB packet limit, so the server rejects it.

Diagnostic Commands

Read the server and session limits (read-only):

mysql -e "SHOW VARIABLES LIKE 'max_allowed_packet';"
mysql -e "SELECT @@global.max_allowed_packet, @@session.max_allowed_packet;"

+--------------------+----------+
| Variable_name      | Value    |
+--------------------+----------+
| max_allowed_packet | 67108864 |
+--------------------+----------+

Find the largest values that might be tripping the limit:

mysql -e "SELECT MAX(LENGTH(data)) AS max_bytes FROM appdb.blobs;"

Check the client default that mysql/mysqldump will use:

mysql --help | grep -A1 max-allowed-packet
mysqldump --help | grep -A1 max-allowed-packet

If a restore failed, inspect the server log for the dropped connection around the failure time:

journalctl -u mysql --since "1 hour ago" --no-pager | grep -i packet

Step-by-Step Resolution

1. Determine the size you actually need. Query MAX(LENGTH(col)) on the offending column, or measure the largest line in the dump file, and pick a max_allowed_packet comfortably above it (round up to a power of two).
2. Raise it on the server. Set max_allowed_packet under [mysqld] in my.cnf (e.g. max_allowed_packet = 256M) and restart, or set it live with SET GLOBAL max_allowed_packet = 268435456; (new connections only — existing sessions keep the old value).
3. Raise it on the client too. For mysql or a restore: mysql --max-allowed-packet=256M. For mysqldump: pass --max-allowed-packet=256M. For connectors, set the equivalent driver parameter.
4. Re-run the operation in a fresh connection so the new session value applies.
5. For replication 1153, raise max_allowed_packet on the replica to at least the source’s value and restart the replica threads.
6. If the cause is an oversized bulk insert, also consider reducing batch size in the application instead of only raising the limit.

Prevention and Best Practices

• Set a consistent max_allowed_packet across server, clients, and replicas — mismatches are the most common cause of intermittent 1153s.
• Keep the limit large enough for your biggest legitimate row but not arbitrarily huge; each connection can allocate up to this size, so very large values raise memory pressure.
• Store large binary objects (images, files) in object storage and keep only references in the database, avoiding multi-megabyte BLOBs entirely.
• Cap application bulk-insert batch sizes so a single statement never approaches the packet limit.
• For dumps you intend to restore, generate them with a known packet size and document the matching restore flag.

Related Errors

• ERROR 2006 (HY000): MySQL server has gone away — frequently the visible symptom when a too-large packet drops the connection mid-restore.
• ERROR 2013 (HY000): Lost connection to MySQL server during query — another connection-drop symptom of oversized or slow transfers.
• Packet too large warnings in the error log — the server-side counterpart logged when it rejects a packet.
• ERROR 1301 (HY000): Result of ... was larger than max_allowed_packet — a function result exceeding the limit.

Frequently Asked Questions

Does raising max_allowed_packet need a restart? Setting it globally with SET GLOBAL takes effect for new connections without a restart, but only persisting it in my.cnf survives a restart. Existing sessions keep their old session value.

Why does it still fail after I raised it on the server? The client almost certainly has a smaller limit. Add --max-allowed-packet to mysql/mysqldump or set the connector parameter.

What is a safe maximum value? The protocol caps it at 1 GB. Most workloads stay well under 256 MB; pick the smallest value that fits your largest legitimate row.

Is SQLSTATE 08S01 specific to this error? No — 08S01 is a general communication-link failure used by several connection errors. With the “packet bigger than” text it specifically indicates the packet-size limit.

Could this be a sign of corruption? Rarely. A malformed length field can make the server read a giant value, but the overwhelming majority of 1153s are simply genuinely large data versus a small limit. For a fast restore failure triage, see more MySQL guides.