Fix 'Got a packet bigger than max_allowed_packet bytes' Error in MySQL

What Just Happened

You were running an INSERT or LOAD DATA INFILE — maybe importing a SQL dump, storing a blob, or pushing a large JSON payload — and MySQL threw this:

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

MySQL sends data between client and server in packets. The max_allowed_packet variable sets the ceiling on how large a single packet can be, which effectively limits the size of any single row or query. Older MySQL versions default to 4 MB; MySQL 8.0 bumped that to 64 MB. Either way, if your data blows past the cap, the server drops the whole operation.

This tends to bite you when:

• Importing a .sql dump that contains large BLOB or TEXT data
• Inserting base64-encoded images or PDFs into a MEDIUMBLOB/LONGBLOB column
• Pushing a fat JSON column value through an ORM
• Running mysqldump on one server and restoring on another with a lower limit

Debug: Find the Current Limit

Before touching anything, check what both the client and server are actually using.

-- Run inside mysql client
SHOW VARIABLES LIKE 'max_allowed_packet';

You'll get something like:

+--------------------------+---------+
| Variable_name            | Value   |
+--------------------------+---------+
| max_allowed_packet       | 4194304 |
+--------------------------+---------+

That number is in bytes. 4194304 = 4 MB. Trying to insert a 20 MB blob? There's your answer.

Also pull the session-level value — global and session can diverge if someone changed it at runtime:

SHOW SESSION VARIABLES LIKE 'max_allowed_packet';

Solution 1: Increase max_allowed_packet in my.cnf (Permanent Fix)

For production, this is the right fix. Open MySQL's config file — the exact path depends on your distro:

• /etc/mysql/mysql.conf.d/mysqld.cnf (Ubuntu/Debian)
• /etc/my.cnf (CentOS/RHEL)
• /etc/mysql/my.cnf

Add or update the [mysqld] section:

[mysqld]
max_allowed_packet = 128M

Then update [mysql] so the client limit matches. A mismatch here causes confusing failures that look like the server is ignoring your config:

[mysql]
max_allowed_packet = 128M

Restart MySQL to pick up the change:

# Ubuntu/Debian
sudo systemctl restart mysql

# CentOS/RHEL
sudo systemctl restart mysqld

Pick a size that covers your largest expected payload. Common choices: 64M, 128M, 256M. Hard cap is 1 GB (1G).

Solution 2: Set It Dynamically (No Restart Needed)

Can't restart right now — say it's peak traffic on a live server? Change the global value at runtime instead. Just know it resets on the next restart unless you also update my.cnf.

-- Requires SUPER or SYSTEM_VARIABLES_ADMIN privilege
SET GLOBAL max_allowed_packet = 128 * 1024 * 1024; -- 128 MB

One catch: the change doesn't apply to already-open connections. Reconnect your client session after running this.

Solution 3: Pass the Flag When Importing a SQL Dump

If the error hits during a mysql import, you can set the packet size directly on the command line — no server config needed:

mysql --max_allowed_packet=128M -u root -p your_database < dump.sql

This raises the client-side limit for that session only. The server still has to accept the packet, so this only works cleanly when you control both sides or the server limit is already high enough.

Solution 4: Increase It When Dumping Too

Sometimes the error shows up during mysqldump itself — the dump is generating SQL statements that are already oversized. Same fix, same flag:

mysqldump --max_allowed_packet=128M -u root -p your_database > dump.sql

Verify the Fix

After restarting MySQL (or running SET GLOBAL and reconnecting), confirm the new value took effect:

SHOW GLOBAL VARIABLES LIKE 'max_allowed_packet';

With 128 MB set, you should see:

+--------------------------+-----------+
| Variable_name            | Value     |
+--------------------------+-----------+
| max_allowed_packet       | 134217728 |
+--------------------------+-----------+

134217728 = 128 × 1024 × 1024 = 128 MB. Now retry the failing operation. For a dump import:

mysql -u root -p your_database < dump.sql
echo "Exit code: $?"

Exit code 0 means it worked.

Still Failing After Increasing the Limit?

A few things can trip you up even after you've made the change:

• Multiple config files winning: MySQL reads config from several locations, and a later file can override your setting with a lower value. Run mysql --verbose --help | grep -A 1 'Default options' to see exactly which files load and in what order.
• Open connections keeping the old value: SET GLOBAL only affects new connections. Any session already open before you ran the command is still using the old limit — disconnect and reconnect.
• Driver-side caps: JDBC, Python's mysqlclient, and other connectors sometimes have their own max_allowed_packet setting baked into the connection string or driver config. Check there too.
• Wrong column type for the data size: BLOB tops out at 65 KB. MEDIUMBLOB goes up to 16 MB. LONGBLOB handles up to 4 GB. If you're stuffing 10 MB into a plain BLOB column, no packet size increase will help — you need to alter the column type first.

Lessons Learned

• Set max_allowed_packet in both [mysqld] and [mysql] — always. A mismatch between server and client limits causes failures that look random until you realize the two values are out of sync.
• When spinning up a new MySQL instance that handles any file or binary data, bump max_allowed_packet to at least 64M from day one. The 4 MB default is a relic — most modern apps will hit it sooner or later.
• The mysql --verbose --help trick for listing config files is criminally underused. It's the fastest way to confirm your edits are actually being read, not silently shadowed by another file.
• When juggling config files across formats or troubleshooting syntax issues, I'll sometimes paste a snippet into the YAML ↔ JSON Converter on ToolCraft to sanity-check structure. Nothing gets uploaded — it all runs in the browser.