How to Fix MySQL Error 1153: Max Allowed Packet Size Exceeded

ERROR 1153 (08S01): Got a packet bigger than 'max_allowed_packet' bytes is raised when a single MySQL communication packet — a query, a result set row, or a binary log event — exceeds the max_allowed_packet server variable. The connection is reset after the error.

Impact

A packet-size error aborts the current statement, closes the connection, and requires the client to reconnect. For applications that send large BLOB, TEXT, or JSON payloads to MySQL, this becomes a hard failure that cannot be retried without also reducing the payload. In replication, a large row-based binary log event can stall the replica entirely if the replica's max_allowed_packet is smaller than the primary's — this is one of the most common causes of silent replication breakage after a schema change that adds a LONGBLOB column.

Common Causes

1. Inserting or updating a BLOB, MEDIUMBLOB, LONGBLOB, TEXT, MEDIUMTEXT, LONGTEXT, or large JSON column with a value that exceeds max_allowed_packet
2. A SELECT that returns a single very large row (e.g., a row with multiple large columns) that exceeds the packet size on the result path
3. Client-side max_allowed_packet set lower than the server's — the client refuses to send or receive the packet even if the server would allow it
4. Replication: the primary's binary log event for a large-row write is rejected by the replica because the replica's max_allowed_packet is smaller
5. mysqldump or mysqlpump output containing a large INSERT with many rows in a single statement (controlled by --max-allowed-packet on the dump tool)
6. GROUP_CONCAT returning a result that exceeds max_allowed_packet (also limited by group_concat_max_len)
7. Stored procedure or function returning a large result set row
8. ORM automatically sending the full object graph in a single parameterized query that grows beyond the limit
9. Compression enabled on the protocol — the uncompressed size still counts against max_allowed_packet

Troubleshooting and Resolution Steps

1. Check the current setting on the server:

   SHOW VARIABLES LIKE 'max_allowed_packet';
   

   The default is 64 MB in MySQL 8.0 (4 MB in older versions). The maximum is 1 GB.

2. Check the client-side setting — each client library has its own limit that must also be raised. For the mysql CLI:

   mysql --max-allowed-packet=512M -u root -p
   

   For mysqldump:

   mysqldump --max-allowed-packet=512M mydb > dump.sql
   

3. Raise the limit on the server for the current session:

   SET SESSION max_allowed_packet = 536870912;  -- 512 MB
   

   Note: max_allowed_packet can only be set globally or at session level; it cannot be set per-user. Session changes take effect for the next packet, not the current one.

4. Raise the global limit (takes effect for new connections):

   SET GLOBAL max_allowed_packet = 536870912;
   
   -- Persist across restarts (MySQL 8.0+)
   SET PERSIST max_allowed_packet = 536870912;
   

   In my.cnf / my.ini:

   [mysqld]
   max_allowed_packet = 512M
   
   [mysql]
   max_allowed_packet = 512M
   
   [mysqldump]
   max_allowed_packet = 512M
   

   Set the same value under [mysqld], [mysql], and [mysqldump] — each section governs a different component.

5. Fix replication packet-size mismatches. The replica must have max_allowed_packet ≥ the primary's:

   -- On the primary
   SHOW VARIABLES LIKE 'max_allowed_packet';
   
   -- On the replica — must be >= primary value
   SET GLOBAL max_allowed_packet = 536870912;
   SET PERSIST max_allowed_packet = 536870912;
   

   Check current replica lag and errors:

   SHOW REPLICA STATUS\G   -- MySQL 8.0+
   SHOW SLAVE STATUS\G     -- MySQL 5.7
   

   Look for Last_IO_Error or Last_SQL_Error mentioning packet size.

6. Identify which column is causing the problem. If you know the table, check column types:

   SELECT column_name, column_type, character_maximum_length
   FROM information_schema.columns
   WHERE table_schema = 'mydb'
     AND table_name = 'mytable'
   ORDER BY ordinal_position;
   

   Then check actual data sizes:

   SELECT id, LENGTH(blob_column) AS size_bytes
   FROM mytable
   ORDER BY size_bytes DESC
   LIMIT 10;
   

7. Cap GROUP_CONCAT output separately:

   SHOW VARIABLES LIKE 'group_concat_max_len';
   
   SET SESSION group_concat_max_len = 1048576;  -- 1 MB
   

   A GROUP_CONCAT result that exceeds group_concat_max_len is silently truncated; one that exceeds max_allowed_packet errors.

8. Stream large BLOBs outside MySQL. The correct long-term solution for payloads above a few MB is to store them in object storage (S3, GCS, Azure Blob) and save only the URL or key in MySQL:

   ALTER TABLE documents
       ADD COLUMN storage_url VARCHAR(2048) NOT NULL DEFAULT '',
       ADD COLUMN storage_size_bytes BIGINT UNSIGNED NOT NULL DEFAULT 0;
   

   This eliminates the packet-size problem, reduces backup size, and allows CDN delivery.

9. Split large mysqldump inserts to avoid huge single-statement packets:

   # --skip-extended-insert writes one INSERT per row (larger dump, no packet issue)
   mysqldump --skip-extended-insert --max-allowed-packet=128M mydb > dump.sql
   

10. Handle the error in application code by catching the specific error code and surfacing a useful message, rather than letting it propagate as a generic DB error:

    import pymysql
    from pymysql.err import OperationalError
    
    try:
        cursor.execute("INSERT INTO docs (body) VALUES (%s)", (large_content,))
    except OperationalError as e:
        if e.args[0] == 1153:
            raise ValueError(f"Document too large for database storage ({len(large_content)} bytes)")
        raise
    

Additional Information

• max_allowed_packet applies to both the client→server direction (query/data) and the server→client direction (result set rows). A very wide result set row can fail on the result path even if the insert succeeded.
• MySQL 8.0 raised the default from 4 MB to 64 MB specifically because applications using JSON columns frequently exceeded 4 MB.
• The maximum allowed value is 1073741824 bytes (1 GB). The InnoDB row format limits a single LONGBLOB to ~4 GB, but the packet limit is hit long before that.
• Binary log format matters: row-based replication (binlog_format=ROW) encodes the entire before/after image of every changed row into the binary log. A 100 MB BLOB update produces a 200+ MB binlog event. Statement-based replication logs the SQL instead, which is far smaller, but has correctness trade-offs.
• Connection pools may not reconnect automatically after a packet-size error closes the connection. Validate that your pool's health-check query runs after a connection error and drops the dead connection rather than recycling it.

Frequently Asked Questions

Q: I raised max_allowed_packet in my.cnf but the error persists. Why? A: The change requires a MySQL restart (or SET GLOBAL). Also check that you raised it in the [mysqld] section and not just [mysql] or [mysqldump], and that your client library has its own separate setting that also needs updating.

Q: Can I raise max_allowed_packet to 1 GB safely? A: The memory for a packet is allocated on demand per connection, so raising the limit does not consume memory until a large packet arrives. However, if many connections simultaneously send large packets, RAM pressure can be significant. 256–512 MB is typically sufficient for most use cases involving large JSON or BLOB columns.

Q: Why does my replica break after adding a LONGBLOB column, even without inserting any large data? A: Row-based replication writes the full row image for every change, including all columns. Even a NULL LONGBLOB column increases the row event size. If the replica's max_allowed_packet is smaller than the primary's, any full-row event that is now slightly larger can exceed the replica's limit.

Q: How do I check if replication is currently broken by this error? A: Run SHOW REPLICA STATUS\G and look at Last_IO_Error. A packet-size error there reads something like Got fatal error 1236 from source when reading data from binary log: 'log event entry exceeded max_allowed_packet'.

Q: Is there a way to store large files in MySQL efficiently? A: Not really. MySQL is not designed for object storage. For files > 1 MB, use a dedicated object store and keep only references in MySQL. For structured data that happens to be large (e.g., large JSON documents), consider whether the data should be normalized or whether a document store is a better fit.