MySQL Error:
1153

What does this error mean?

MySQL error 1153 fires when a single network packet between client and server exceeds the max_allowed_packet threshold. Every SQL statement, result set row, and prepared-statement parameter travels as a packet — if any one of them is larger than the configured limit (default: 64 MB in MySQL 8.0, 4 MB in 5.7), the connection is dropped and the query fails. In data pipelines this typically surfaces during bulk INSERT of BLOB/LONGTEXT columns, large SELECT result sets being read by an ADF copy activity, or mysqldump restores containing extended INSERT statements. The symptom is an abrupt connection loss: the client sees 'MySQL server has gone away' or 'Got a packet bigger than max_allowed_packet bytes', and the pipeline step fails without writing any rows for that batch.

Common causes

• 1Inserting or updating a BLOB or LONGTEXT value that exceeds max_allowed_packet. A single row with a 70 MB PDF stored in a BLOB column will exceed the 64 MB default.
• 2ADF copy activity reading large rows from MySQL — the result set packet for a single row with multiple TEXT columns can exceed the limit on the MySQL server side, killing the connection mid-transfer.
• 3Restoring a mysqldump file that uses extended INSERT syntax. A single INSERT with thousands of rows concatenated into one statement produces a packet far larger than the row data alone.
• 4MySQL replication breaking when the master writes a binlog event larger than the replica's max_allowed_packet. The replica's I/O thread disconnects and replication stalls until the setting is aligned.
• 5dbt snapshots or incremental models that merge large JSON columns via INSERT ... SELECT, where the intermediate result set exceeds the packet limit before it reaches the server.
• 6Application ORMs (SQLAlchemy, Hibernate) sending batched parameter sets in a single prepared statement, creating a packet proportional to batch_size × row_size.

How to fix it

1. 1Step 1: Check the current server-side limit: `SHOW VARIABLES LIKE 'max_allowed_packet';` — note the value in bytes. Also check the client-side setting if you use mysql CLI or mysqldump: `mysql --print-defaults | grep max_allowed_packet`.
2. 2Step 2: Find how large your actual packets are. Run a query on the problem table to estimate: `SELECT MAX(LENGTH(blob_col)) AS max_bytes FROM your_table;` — this tells you the minimum packet size needed for the largest row.
3. 3Step 3: Set the global variable to at least 2× your largest value (headroom for protocol overhead): `SET GLOBAL max_allowed_packet=268435456;` (256 MB). This applies to new connections only — existing connections keep the old value.
4. 4Step 4: Persist the change in my.cnf so it survives restarts. Add under both `[mysqld]` (server) and `[client]` (CLI tools, mysqldump): `max_allowed_packet=256M`. On Azure Database for MySQL, set it via the Azure Portal under Server Parameters instead.
5. 5Step 5: Restart MySQL to apply the my.cnf change: `sudo systemctl restart mysql`. For Azure Database for MySQL, the portal applies the change after a brief reconnect cycle — no manual restart needed.
6. 6Step 6: If running replication, set max_allowed_packet on every replica to match or exceed the master. Check with: `SHOW SLAVE STATUS\G` — look for Last_IO_Error mentioning packet size.
7. 7Step 7: For ADF copy activities, reduce the writeBatchSize in the sink settings (e.g., from 10000 to 1000) so each INSERT packet stays under the limit even without raising max_allowed_packet on a managed server where you lack SUPER privileges.

Example log output

[2026-05-11 03:14:22] ERROR 1153 (08S01): Got a packet bigger than 'max_allowed_packet' bytes
[2026-05-11 03:14:22] ERROR: Lost connection to MySQL server during query
[2026-05-11 03:14:22] ADF Copy Activity 'CopyMySQLToAdls' failed: MySQL source error — packet size 71303168 bytes exceeds server max_allowed_packet (67108864). Activity will retry (attempt 1 of 4).

Frequently asked questions

Other resource errors