phpMyAdmin Import Failing? Fix 'max_allowed_packet' Errors

You're importing a database dump through phpMyAdmin and it just... stops. Sometimes there's a red error box, sometimes the browser tab just spins and then shows a blank white screen. Nine times out of ten, the culprit is a MySQL setting called max_allowed_packet — and the fix depends on whether you're on shared cPanel hosting or a VPS where you control the my.cnf file.

Symptom: the import dies partway through

You'll usually see one of these, either in the phpMyAdmin UI or in the SQL log it shows after a failed import:

• #2006 - MySQL server has gone away
• Got a packet bigger than 'max_allowed_packet' bytes
• The import bar reaches some percentage (often around a big INSERT INTO statement) and then the page just goes white
• Only part of a table gets imported — row counts don't match the source database

It's almost always tied to one specific table: usually wp_options, wp_postmeta, or any table with large serialized data or BLOB/TEXT columns. Small config tables import fine; the big ones fail.

Cause: MySQL is rejecting a packet, not the whole file

max_allowed_packet isn't a file-size limit — it's a per-packet limit MySQL enforces on any single communication between the client and server. A "packet" in this context is usually one row, or one long INSERT statement if the dump was written with extended inserts (multiple rows bundled into a single statement, which mysqldump does by default).

So a 2 MB SQL file can still fail if it contains one row — say, a plugin's serialized options blob, or a cached page fragment — that's bigger than the server's current max_allowed_packet value. The default on a lot of MySQL/MariaDB installs is only 1M or 4M, which is tight for modern WordPress sites with heavy caching plugins or large postmeta entries.

There's a second, unrelated limit that gets confused with this one: PHP's upload_max_filesize and post_max_size, which cap how big a file phpMyAdmin can even accept for upload in the first place. If your file itself is large (say, 200 MB+), you might be hitting that limit before you ever get to max_allowed_packet. Check which error you're actually getting before you start changing settings — they're fixed in different places.

Fix: check the current value first

Log into phpMyAdmin, open the SQL tab against any database, and run:

SHOW VARIABLES LIKE 'max_allowed_packet';

That tells you what you're working with. Now the fix path splits depending on your hosting type.

On shared cPanel hosting (no root access)

You can't edit my.cnf directly on shared hosting — that file is shared across every account on the server, and cPanel won't expose it to individual users. You have three realistic options:

1. Ask support to raise it. On Getwebup shared plans, this is a five-minute change we can make on your account's MySQL config. Tell us the table name and roughly how large the offending row is (phpMyAdmin will usually show you which INSERT it choked on in the partial import log).
2. Import over SSH instead of the browser. If your plan includes SSH access, the command-line client sidesteps phpMyAdmin's PHP upload limits entirely (though it's still bound by the server's max_allowed_packet):

   mysql -u cpaneluser_dbuser -p cpaneluser_dbname < dump.sql

   This alone fixes most "import hangs at 80% and goes white" cases that were actually PHP timeout issues, not packet issues.
3. Split the dump file. If raising the limit isn't an option, break the SQL file into smaller pieces so no single statement is too large. A quick way, if you have shell access:

   csplit -z dump.sql '/^-- Table structure for/' '{*}'

   Or re-export from the source using mysqldump --skip-extended-insert, which writes one row per INSERT statement instead of bundling them — slower to import, but each packet stays small.

On a VPS or dedicated server (root access)

You control my.cnf directly, so this is a permanent fix. Find your config file — it's usually one of:

• /etc/my.cnf (CentOS/AlmaLinux, cPanel/WHM servers)
• /etc/mysql/mariadb.conf.d/50-server.cnf (Ubuntu/Debian with MariaDB)

Add or edit the setting under the [mysqld] section:

[mysqld]
max_allowed_packet = 256M

Then restart the database service:

systemctl restart mysql
# or, on MariaDB:
systemctl restart mariadb

256M is a generous, safe default for most WordPress and WooCommerce databases. You don't need to go higher unless you're regularly moving multi-gigabyte tables with huge BLOB columns — and if that's the case, you probably want to be splitting the import anyway rather than relying on one massive packet size.

Where to change it: quick reference

That last row is worth knowing about: if you have a privileged MySQL user (not the case on most shared cPanel accounts, but common on a VPS), you can bump the value without touching a config file or restarting anything:

SET GLOBAL max_allowed_packet = 268435456; -- 256M in bytes

It resets to the config file value on the next MySQL restart, so treat it as a one-off for finishing an import you're stuck on right now, not a permanent solution.

Prevention: fix it at export time too

If you're the one creating the dump — say, exporting from a client's old host before migrating to Getwebup — you can avoid the whole problem by controlling how mysqldump writes the file in the first place:

mysqldump -u user -p --max_allowed_packet=256M --single-transaction dbname > dump.sql

The --max_allowed_packet flag here tells mysqldump itself what packet size to negotiate with the source server during export — separate from the setting on the server you're importing into. Match both ends and you won't get surprised on the way in.

A few other habits that keep this from recurring:

• Run WordPress database cleanup periodically (transients, orphaned postmeta, revision bloat) so you're not hauling around unnecessary large rows in every migration.
• For routine migrations, prefer WP-CLI's wp db export / wp db import or SSH-based transfers over the phpMyAdmin UI — it's not just faster, it avoids PHP's separate upload limits stacking on top of MySQL's packet limit.
• If you manage multiple sites on the same VPS, set max_allowed_packet once at the server level rather than fighting it site by site.

Still stuck?

If you've raised max_allowed_packet, restarted MySQL, and the import still fails at the same point, check two things before assuming it's the same issue: disk space (df -h — a full disk produces confusing partial-import failures that look identical), and whether the import is actually timing out on PHP's max_execution_time rather than hitting a packet limit at all. Those two get mistaken for each other constantly.