MySQL "Server Has Gone Away" (Error 2006): Causes and Fixes

"MySQL server has gone away" (client error 2006) means the connection your application was using was closed by the server, or lost, before or during a query. The client tried to send a statement down a connection that no longer exists. A close sibling is error 2013, "Lost connection to MySQL server during query", which happens when the connection drops while a query is running.

You see it in PHP as PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away, in WordPress logs, in Python and Node database drivers, and in long-running workers, cron jobs and queue consumers more than in short web requests.

Causes, most likely first

1. Idle timeout. The connection sat unused longer than wait_timeout, and the server closed it. Common in daemons, queue workers and scripts that do long non-database work between queries.
2. A packet larger than max_allowed_packet. Big inserts, large BLOB or JSON values and bulk imports exceed the limit and the server drops the connection.
3. The server restarted or crashed. All connections die. Often an out-of-memory kill.
4. A query killed or timed out by an administrator, KILL, or a statement timeout setting such as max_execution_time.
5. Network devices closing idle connections. Firewalls, NAT gateways and load balancers drop idle TCP flows after a timeout, which is often shorter than MySQL's.
6. A forked process sharing a connection, a classic bug where a parent and child process use the same socket.

Step 1: did the server restart?

SHOW GLOBAL STATUS LIKE 'Uptime';
SHOW GLOBAL STATUS LIKE 'Aborted_clients';

A small Uptime right after the errors means a restart. Then look for the reason:

sudo journalctl -u mysql --since "1 hour ago" --no-pager | tail -n 50
sudo dmesg -T | grep -i -E "out of memory|killed process"
sudo tail -n 100 /var/log/mysql/error.log

If the OOM killer terminated mysqld, reduce memory settings such as innodb_buffer_pool_size, limit max_connections, or add RAM. See also MySQL too many connections.

Step 2: check timeouts

SHOW VARIABLES LIKE 'wait_timeout';
SHOW VARIABLES LIKE 'interactive_timeout';
SHOW VARIABLES LIKE 'net_read_timeout';
SHOW VARIABLES LIKE 'net_write_timeout';

wait_timeout governs non-interactive clients such as web apps and scripts. If your worker idles for longer than this value, the next query fails. Prefer fixing the client (reconnect or ping) over raising the timeout to an extreme value. If you do change it, set it in the config file so it survives a restart:

[mysqld]
wait_timeout = 600

Remember that your firewall or load balancer may have a shorter idle limit than MySQL, and then the server value does not matter.

Step 3: check max_allowed_packet

SHOW VARIABLES LIKE 'max_allowed_packet';

The default differs between versions and distributions, so check yours. If you import a large dump or insert big values, raise it on the server and for the client tool:

[mysqld]
max_allowed_packet = 128M

[mysqldump]
max_allowed_packet = 128M

mysql --max-allowed-packet=128M dbname < dump.sql

Setting it dynamically with SET GLOBAL max_allowed_packet = 134217728; applies to new connections only; reconnect to see it. The server error log may show "Got a packet bigger than 'max_allowed_packet' bytes" when this is the cause.

Step 4: make the application tolerate reconnects

Even a healthy server closes idle connections, so long-running code should handle it.

• Reconnect on failure. Catch error 2006 and 2013, open a new connection and retry the statement. Retry only idempotent operations, or use transactions.
• Ping before use. Python's connection.ping(reconnect=True) and Node pool libraries with a validation query do this.
• Use connection pools that expire connections before the server does, for example a max lifetime of a few minutes, lower than wait_timeout and any firewall limit.
• Do not share connections across forks. Open a new connection in each child process.
• WordPress. Plugins with long imports or WP-Cron jobs can trigger it; check WP-Cron explained and fixed and monitor scheduled jobs with Cron Monitoring.

How to verify

Re-run the failing job or import and confirm it completes. For idle-timeout fixes, leave a test script idle past the previous failure threshold and confirm it still works. Check that Uptime is steady and Aborted_clients stops climbing. Use the Website Health Check and HTTP Status Checker on affected pages, and put important scheduled jobs under Cron Monitoring so a silent failure alerts you.

Next steps

• Check reachability with the Port Checker.
• Monitor scheduled workers with Cron Monitoring.
• Read MySQL error 2002 if connections are refused outright.
• Add an Uptime Monitor for database-backed pages.

FAQ

What is the difference between error 2006 and 2013?

2006 means the connection was already gone when the client sent the query. 2013 means the connection dropped while the query was running, which often points to a crash, a timeout or a killed query.

Should I just set wait_timeout to a huge number?

Not usually. Idle connections consume server resources and can contribute to hitting the connection limit. Reconnect logic and sensible pool lifetimes are safer.

Why does it only happen during large imports?

Large statements can exceed max_allowed_packet, or a long-running statement can hit a read or write timeout. Raise the packet size and split inserts into batches.

Can a bad query cause the server to go away?

A query that crashes the server will drop every connection and appears as a restart in the error log. Update MySQL and look for the statement in the log.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.