TL;DR: To increase
max_allowed_packetpermanently, addmax_allowed_packet=1Gunder[mysqld]inmy.cnfand restart MySQL. For an immediate fix without a restart, runSET GLOBAL max_allowed_packet=1073741824;in a MySQL client. Confirm the change withSHOW VARIABLES LIKE 'max_allowed_packet';.
Contents

When MySQL receives a query with a data packet larger than the max_allowed_packet value, it throws a "Packet too large" error and closes the connection. This is a common MySQL error in WordPress environments. It surfaces during a WP STAGING push, large database imports, and site migrations. The default value is set low relative to what large WordPress sites need, but increasing it is straightforward once you identify the right method for your hosting environment.
For example, if a WP STAGING backup restore fails because of a too-small packet size, the error message shows the size of the offending query so you can adjust max_allowed_packet accordingly. In the current version of WP STAGING, the plugin throttles and executes database queries dynamically based on your server’s maximum allowed packet size, but the underlying MySQL limit still applies to direct imports and third-party tools.
You have two options to change the MySQL max_allowed_packet size: a permanent change in the MySQL configuration file, and a temporary change via SQL. Both are covered below.
What max_allowed_packet Controls
The max_allowed_packet system variable sets the maximum size of a single communication packet between the MySQL client and server. When a query, result row, or stored routine definition exceeds this limit, MySQL terminates the connection and logs an error.
Common symptom patterns:
- "Packet too large": MySQL rejects the query immediately.
- "MySQL server has gone away": the connection drops during a long-running import.
- Push or restore failures in WP STAGING when the site contains large post revisions, serialized option values, or image metadata stored as post meta.
- Errors during
mysqldumprestoration or phpMyAdmin import.
In our support queue, the most common trigger is a WP STAGING push that includes large image libraries or post revisions stored as post meta. We have also seen it block migrations to a new host. Catching the limit before a migration avoids failed imports mid-transfer.
Which Method Should I Use?
| Your environment | Best method |
|---|---|
| VPS or dedicated server with SSH access | Edit my.cnf (permanent) |
| Shared hosting (no SSH) | Contact your host; phpMyAdmin can inspect the current value but not change it permanently |
| AWS RDS for MySQL | Modify a DB parameter group in the AWS console |
| DigitalOcean Managed MySQL | Set via the "Configuration" tab in the control panel |
| Need an immediate fix without a restart | SET GLOBAL SQL command (temporary, resets on restart) |
If you are unsure which config file MySQL is reading, run mysql --verbose --help | grep my.cnf in a terminal to see the full search order.
How to Set max_allowed_packet Permanently
A permanent change survives MySQL server restarts. The method depends on your hosting environment.
Before you change anything, check the current value so you know your starting point. On a server with SSH access, run SHOW VARIABLES LIKE 'max_allowed_packet'; in a MySQL client; on shared hosting, open phpMyAdmin, then Variables, and search for max_allowed_packet. Set your new value comfortably above the largest packet you expect: when a restore or import fails, the error message reports the size of the offending query, so use that figure as your floor.
VPS or Dedicated Server: Edit my.cnf
1. Open the MySQL config file. Open my.ini (Windows) or my.cnf (Linux or macOS) in the MySQL server installation directory. On most Linux systems the file is at /etc/mysql/my.cnf or /etc/my.cnf. If you are not sure which file MySQL reads, verify the exact path first with mysql --verbose --help | grep my.cnf.
2. Find the [mysqld] section. The directive must go under [mysqld], not [mysql] or [client]. Placing it in the wrong section is the most common reason the fix appears to work but has no effect.
3. Set the value. Find or add the max_allowed_packet line under [mysqld]. To set it to 1 GB:
[mysqld]
max_allowed_packet=1G
4. Save the file and restart MySQL.
sudo systemctl restart mysql
5. Verify the new value.
SHOW VARIABLES LIKE 'max_allowed_packet';
On shared hosting without SSH access, you can check the current max_allowed_packet value by navigating to phpMyAdmin, then Variables, and searching for max_allowed_packet. To increase it permanently, contact your hosting provider, because this is a server-level setting that requires administrative access outside the shared control panel.
Managed Databases: AWS RDS and DigitalOcean
Cloud-managed MySQL services expose the variable through their control panels rather than a config file:
- AWS RDS for MySQL: open the DB instance in the AWS console, navigate to its associated parameter group, and set
max_allowed_packet. Apply the updated parameter group and reboot the instance for the change to take effect. - DigitalOcean Managed MySQL: navigate to your database cluster’s Configuration tab and update
max_allowed_packetthere.
For both platforms, set the value before a large migration to a new host so the import does not fail partway through.
How to Set max_allowed_packet Temporarily
The max_allowed_packet variable can be set globally with a single SQL command. This takes effect immediately, with no restart required, but the value resets when the MySQL server restarts. Always follow up with the permanent my.cnf edit if you need the change to persist.
To change the max allowed packet for everyone to 1 GB until the server restarts:
SET GLOBAL max_allowed_packet=1073741824;
Verify immediately:
SHOW VARIABLES LIKE 'max_allowed_packet';
This method is useful for unblocking a restore or import that is failing right now, or for testing the correct value before committing it to the config file.
What to Do If the Fix Does Not Take Effect
If SHOW VARIABLES LIKE 'max_allowed_packet'; still returns the old value after your change, work through this checklist:
1. Wrong config section. The directive must be under [mysqld]. Open the file and confirm the section header directly above the max_allowed_packet line.
2. Wrong config file. MySQL reads multiple files in a specific order and the last matching value wins. Check the actual search path:
mysql --verbose --help | grep my.cnf
3. MySQL was not restarted. Confirm the service restarted successfully:
sudo systemctl status mysql
4. File not saved or not readable. Verify the file was saved and that MySQL has read permission on it.
5. Replica nodes. In a replicated environment, SET GLOBAL applies only to the node you connected to. Each replica requires its own config file update.
6. Client-side limit. Some database clients set max_allowed_packet at connection time. If the client value is lower than the server value, the client limit applies regardless of the server setting.
We have seen the fix fail silently when the [mysqld] section header was missing from a freshly provisioned my.cnf that contained only [mysql] entries. MySQL parses the file without errors but ignores the directive.
Server memory limit errors sometimes appear alongside MySQL packet errors in the same log file. See PHP memory_limit exhausted errors for that fix, which follows the same config-section discipline. For PHP’s max_input_vars limit, editing the server config file resolves it the same way.
Related Articles
- How to Increase PHP Max Input Vars Limit in WordPress
- How to Increase the Maximum Upload File Size in WordPress
- How to Change WordPress Table Prefix of mySQL Database
- 3 Ways to Change the WordPress Database Table Prefix
- Fix Missing PHP MySQL Extension in WordPress
- phpMyAdmin Repair and Optimize Database Tables Tutorial
- MySQL Error – "Row size too large" while Restoring a Backup