MySQL Server Has Gone Away
Error 2006 (MySQL server has gone away) means the client's connection to the server died before a reply arrived. Read the timing: a drop during a large import points to max_allowed_packet, an idle gap points to wait_timeout, and every connection failing at once means mysqld restarted or was killed.
For WordPress owners, importers and VPS admins who need error 2006 gone today, written against MySQL 8 and MariaDB defaults.
knowledge
- Read time
- 5 min
- Sections
- 7
- Updated
- 14 Nov 2026
- Written by
- WebJi® team
Last editorial update: 15 November 2026.
What does MySQL error 2006 actually mean?
MySQL error 2006 (CR_SERVER_GONE_ERROR) means the client tried to talk to the server on a connection that had already closed, so the statement never completed. The wording — "MySQL server has gone away" — survives unchanged whether it surfaces in a PHP log, a phpMyAdmin import or the mysql command line, which is why the message alone cannot tell you what to change.
Two nearby codes get confused with it. Error 2006 usually means the link was dead before or while sending the packet; error 2013 ("Lost connection to MySQL server during query") means the server dropped the connection while the statement was running — often a long query killed by a timeout or memory limit. The log lines immediately around the error, plus the time of day, are the real diagnostic.
- One query dies, the rest work: the packet was too large or that one query ran too long.
- A connection that sat unused dies on its first use: the server closed an idle link.
- Every page fails at the same second: mysqld restarted, crashed, or was killed for memory.
- Only imports and restores fail: packet size, not timeouts.
Which of the four causes do you have?
Match the symptom to a cause before editing any variable, because each cause has a different fix and raising the wrong one wastes an hour. Run the check command from the table below in phpMyAdmin's SQL tab or a mysql shell; both read the same server variables.
| What you see | Likely cause | First command |
|---|---|---|
| Fails mid-import, mid-restore or on one large INSERT | max_allowed_packet too small | SHOW VARIABLES LIKE 'max_allowed_packet'; |
| Fails after minutes of inactivity, fine after reload | wait_timeout closed the idle link | SHOW VARIABLES LIKE 'wait_timeout'; |
| Every connection fails; uptime is minutes old | mysqld restarted or was OOM-killed | mysqladmin version |
| Only one table or query fails | Crashed table or a lock | CHECK TABLE table_name; |
Fix 1: the packet is bigger than max_allowed_packet
When a single statement exceeds max_allowed_packet, MySQL closes the connection rather than apply half a statement, and the client reports the server as gone. MySQL 8.0 defaults to 64 MB on the server side and 16 MB on the client side; current MariaDB releases ship 16 MB. A multi-row INSERT from a dump, a LONGTEXT column or a base64-encoded blob is what usually crosses the line.
- Read the value:
SHOW VARIABLES LIKE 'max_allowed_packet';— values are bytes, so 67108864 is 64 MB. - Change it live:
SET GLOBAL max_allowed_packet = 268435456;(256 MB). New connections pick it up; existing ones do not. The ceiling is 1 GB. - Persist it: add
max_allowed_packet=256Munder[mysqld]and under[client]inmy.cnf, so the client agrees with the server. - Restart and confirm:
systemctl restart mysql, then re-run the SHOW VARIABLES check.
For a one-off import you can skip the restart entirely and put the flag on the command itself — it raises the sending side, which is where the limit bites:
mysql --max_allowed_packet=256M dbname < dump.sqlSuffixes in my.cnf are case-insensitive (256M equals 256m), and buffer memory is allocated per connection, so avoid "just in case" values like 1 GB on a busy shared server.
Fix 2: wait_timeout closed the idle connection
If the connection sat idle longer than wait_timeout seconds, the server closes it, and the first query on the stale link fails with error 2006. The default is 28800 seconds (8 hours) on stock MySQL and MariaDB, but shared hosts and managed stacks often trim it to 60–120 seconds, which is where WordPress cron jobs and long-running PHP workers get caught.
- Read both timers:
SHOW VARIABLES LIKE 'wait_timeout';and the same forinteractive_timeout. - Raise it if your app holds links open:
SET GLOBAL wait_timeout = 300;then persistwait_timeout=300under[mysqld]inmy.cnf. - Check the PHP side:
default_socket_timeoutand the MySQL connect timeout must not be shorter than the server's wait timeout, or the client gives up first.
A shorter connection is a better fix than a longer timeout: open the link per batch of work, or use a pool that pings the connection before reusing it. An idle connection held overnight is what created the stale link in the first place.
Fix 3: the server restarted or was killed for memory
When every connection drops at the same moment, mysqld itself died — a hosting problem, not a query problem, and no application setting will fix it. Memory exhaustion is the most common trigger on small VPS plans: the Linux OOM killer picks mysqld when RAM runs out.
- Check uptime:
mysqladmin version— Uptime in minutes means a restart; days rule one out. - Read the error log: usually
/var/log/mysql/error.logor/var/log/mysqld.log, around the failure timestamp. - Name the killer:
dmesg -T | grep -i kill— an "oom-kill" line means RAM, not MySQL, is the culprit. - Right-size memory: set
innodb_buffer_pool_sizeto roughly half of RAM, stop competing services, restart.
A single crashed table can imitate this, because the query stalls until the client surrenders. CHECK TABLE name; then REPAIR TABLE name; will say — and an InnoDB table normally recovers by itself at startup. The full repair-and-optimize routine is covered in repairing and optimising a MySQL database. On unmanaged VPS hosting you own this diagnosis; on shared hosting, send the timestamp to support.
Why big imports trip error 2006 most often
A restore is the classic trigger because a dump fires thousands of multi-row INSERTs as fast as the pipe allows, and any one statement can exceed the packet ceiling. Three flags on the dump and import commands make the pair survive.
mysqldump --max_allowed_packet=256M --single-transaction dbname > dump.sql
mysql --max_allowed_packet=256M dbname < dump.sql- --max_allowed_packet on both sides — the client default (16 MB) is smaller than the server's, so the client is often the one refusing.
- --single-transaction on the dump — a consistent export without table locks (InnoDB only).
- --net_buffer_length=16384 — starts each statement buffer small, which helps on hosts where the server value cannot be raised.
If the server value is fixed anyway, split the restore by table: mysqldump dbname table_name > table.sql, import each file, and cut a very large table further with --where="id BETWEEN 1 AND 100000". The phpMyAdmin route, with its own limits and chunking tactics, is detailed in importing a large SQL file through phpMyAdmin.
Frequently asked questions
How do I fix MySQL server has gone away?
Read the timing, then change one thing. A failure during a large import needs a larger max_allowed_packet on the server and the client. A failure after an idle gap needs a longer wait_timeout or a connection that reconnects before use. If every connection died at once, read the MySQL error log and check uptime.
What is the default max_allowed_packet?
MySQL 8.0.3 and later default to 64 MB (67108864 bytes) on the server and 16 MB on the client side, with a hard maximum of 1 GB. Current MariaDB releases default to 16 MB. Because the client value is the smaller one, an import can fail even when the server looks generously configured.
Why does the error appear only during big imports?
A dump sends large multi-row INSERT statements in a tight stream, and one statement can exceed the packet ceiling. The server closes the connection rather than apply half a statement, so the client reports the server as gone even though mysqld is healthy the whole time.
Does raising max_allowed_packet use more RAM?
Yes, potentially — packet and connection buffers are allocated per connection, so a large global value multiplied by many concurrent connections adds up. 256 MB is plenty for WordPress and WooCommerce imports; reserve 1 GB values for one-off restores, not everyday configuration.
Is error 2006 a hosting problem or a code problem?
Both are possible and the log decides. One query or one import failing points at packet size or code. Every connection failing at once, with young uptime and oom-kill lines in dmesg, points at the server — and belongs with the host, not your application.
Last editorial update: 15 November 2026. Defaults checked against the MySQL 8.0 reference manual; MariaDB figures follow its published defaults.
Ready to get started with WebJi®?
Join 12,000+ businesses across India and overseas. INR pricing, 18% GST shown before payment and 24/7 email support in Hindi and English — average first reply under 60 minutes.