MySQL: got a packet bigger than ‘max_allowed_packet’ bytes - causes and fixes

ER_NET_PACKET_TOO_LARGE (MySQL error 1153) drops the connection immediately. The payload crossed a limit on the client, the server, or a replica. A common mistake is tuning only the server: a source set to 256 MB still aborts a 20 MB payload if the mysql client is at its default 16 MB. Replicas add their own hard and soft ceilings. This guide shows how to identify which boundary failed, raise it without a restart where possible, and prevent recurrence.

What this means

MySQL frames every request, result set, and replication event as a discrete protocol packet. max_allowed_packet sets the upper bound for a single packet. On the server the default is 64 MB in MySQL 8.0 and later; earlier versions default to 4 MB. The mysql command-line client defaults to 16 MB regardless of the server setting. When a packet exceeds the receiver’s limit, the server emits ER_NET_PACKET_TOO_LARGE and closes the connection. Some clients surface it as Lost connection to MySQL server during query, so check the server error log before chasing network issues. The packet buffer is allocated per connection and grown as needed, so raising the limit does not reserve extra RAM for every connection.

In row-based replication, the limit often behaves differently than expected. max_allowed_packet bounds the packet buffer used for replication traffic; row events encode the entire row image, so a single event can exceed the limit even when individual columns are small. Row-based UPDATE statements with binlog_row_image = FULL transmit both before and after images, so a narrow update on a wide table can generate a large event. Replicas have a hard ceiling, replica_max_allowed_packet, which defaults to 1 GB and prevents the replica I/O thread from failing when the source sends large events. Even when an event fits under that hard ceiling, a secondary soft limit, replica_pending_jobs_size_max, can stall multi-threaded apply and create replication lag.

flowchart TD
    A[Large packet or row event] --> B{Server limit exceeded?}
    B -->|Yes| C[Server aborts connection]
    B -->|No| D{Client limit exceeded?}
    D -->|Yes| E[Client fails mid-query]
    D -->|No| F{Replica limit exceeded?}
    F -->|Yes| G[Replica IO thread stops]
    F -->|No| H[Request succeeds]
    C --> I[Aborted_clients rises]
    E --> I
    G --> J[Seconds_Behind_Source grows]

Common causes

Quick checks

-- Server limit in bytes
SHOW GLOBAL VARIABLES LIKE 'max_allowed_packet';

# Client default limit
mysql --help | grep max_allowed_packet

-- Replica hard ceiling
-- MySQL 8.0+
SHOW GLOBAL VARIABLES LIKE 'replica_max_allowed_packet';
-- 5.7 and earlier
SHOW GLOBAL VARIABLES LIKE 'slave_max_allowed_packet';

-- Connection aborts that may point to packet issues
SHOW GLOBAL STATUS LIKE 'Aborted_clients';
SHOW GLOBAL STATUS LIKE 'Aborted_connects';

-- Replica thread errors
-- MySQL 8.0+
SHOW REPLICA STATUS\G
-- 5.7 and earlier
SHOW SLAVE STATUS\G

-- Row image and parallel-apply soft limit
SHOW GLOBAL VARIABLES LIKE 'binlog_row_image';
SHOW GLOBAL VARIABLES LIKE 'replica_pending_jobs_size_max';

How to diagnose it

1. Identify the boundary. Compare the payload size to the server’s max_allowed_packet. Then check the client tool or driver limit separately. A server setting of 256 MB means nothing if the mysql client is still at 16 MB.
2. Correlate with Aborted_clients. A jump in Aborted_clients without matching authentication failures (Aborted_connects) suggests protocol-level drops, including packet-too-large events.
3. Inspect replication errors. On the replica, SHOW REPLICA STATUS\G reveals Last_IO_Error and Last_SQL_Error. If the I/O thread stopped after a large write on the source, the event may exceed replica_max_allowed_packet or the replica’s incoming buffer reservation.
4. Measure the row or event. For tables with large BLOB/TEXT columns, check approximate sizes. Row-based replication sends unchanged columns too. An UPDATE that touches a 50 MB TEXT column moves 50 MB through the replication stream even if the text did not change.
5. Review dump procedures. mysqldump with extended inserts produces large VALUES blocks. The restore client needs --max_allowed_packet sized to match the largest insert block, not just the server.
6. Rule out corruption. If the error mentions a packet size larger than 1 GB, the protocol maximum, suspect a corrupted binary log or relay log event. Inspect the position with mysqlbinlog. Do not attempt to raise max_allowed_packet above 1 GB; the server caps it.
7. Check multi-threaded replica stalls. On replicas with replica_parallel_workers > 0, events larger than replica_pending_jobs_size_max drain all worker queues and serialize apply, producing lag that looks like a slow query problem.

Metrics and signals to monitor

Fixes

Raise the server limit

Change dynamically:

SET GLOBAL max_allowed_packet = 268435456;

Use a byte value; SET GLOBAL does not accept M/G suffixes. Persist the value under [mysqld] in my.cnf. New connections pick up the global value; existing connections keep their session value unless you reconnect or run SET SESSION max_allowed_packet = ....

Raise the client limit

For the mysql client:

mysql --max_allowed_packet=256M -u user -p database < large_dump.sql

For application drivers, set the equivalent parameter (for example, maxAllowedPacket in Connector/J). Add the value to [mysql], [mysqldump], and [client] sections of my.cnf so CLI tools pick it up by default.

Adjust replica limits

On the replica:

SET GLOBAL replica_max_allowed_packet = 1073741824;

If multi-threaded apply sees lag rather than hard failures, raise replica_pending_jobs_size_max. This increases the memory the coordinator can queue for workers, so size it to available replica RAM.

Shrink the payload

If you are near the 1 GB protocol hard limit, application-level chunking is the only path. Split large BLOB/TEXT inserts into smaller fragments. For row-based replication, set binlog_row_image = MINIMAL if the workload tolerates it, so only changed columns are transmitted.

Handle corrupted log events

When mysqlbinlog shows a corrupted event reporting an impossible size, do not raise limits to compensate. Skipping the position with CHANGE REPLICATION SOURCE TO (or CHANGE MASTER TO on older versions) creates a data gap and should only be done after explicit risk acceptance. The safer path is usually to rebuild the replica from a fresh backup.

Prevention

• Define max_allowed_packet in both [mysqld] and [client] sections of the configuration file. Do not assume the client inherits the server value.
• Validate dump and restore paths in staging with production-sized rows to catch client-side limits before an incident.
• Size replica buffers proactively before bulk load windows.
• Monitor Aborted_clients baseline continuously. A gradual rise often warns of an approaching limit breach.
• Audit wide tables with large TEXT/BLOB columns. Enforce application chunking for objects approaching 100 MB.

How Netdata helps

Netdata surfaces these signals on one timeline: Aborted_clients and Aborted_connects spikes, Threads_connected saturation, replica thread state, and Seconds_Behind_Source lag. Use them to separate packet-size disconnects from authentication or network issues, and to alert on Aborted_clients rate deviations without polling SHOW GLOBAL STATUS.

Related guides

• How MySQL actually works in production: a mental model for operators
• MySQL connection exhaustion: detection, diagnosis, and prevention
• MySQL monitoring checklist: the signals every production instance needs
• MySQL monitoring maturity model: from survival to expert
• MySQL ERROR 1040 (HY000): Too many connections - causes and fixes