Fix: ERROR 2006 (HY000): MySQL server has gone away

You ran a query and MySQL returned ERROR 2006 (HY000): MySQL server has gone away. This means the client had an open connection, sent a statement, and the server closed that connection before or during the exchange. The error is a symptom, not a root cause. The connection can drop for several unrelated reasons, and the fix for one will do nothing for another. The goal here is to tell them apart quickly, then apply the right change.

What this error means

The MySQL client protocol expects a live TCP connection for the duration of a statement. Error 2006 is raised by the client when the server has closed that socket unexpectedly. A closely related error, ERROR 2013 (HY000): Lost connection to MySQL server during query, usually points at the same underlying causes. The connection may have been closed because a limit was exceeded, an idle timeout fired, or the server process itself went down and came back.

Common causes

• The statement or a BLOB value exceeded max_allowed_packet, so the server rejected the packet and closed the connection. The failure lands on or near a large query.
• An idle connection outlived wait_timeout (or interactive_timeout for interactive clients), so the server closed it. The next query on a pooled connection then fails.
• The server actually crashed, was OOM killed, or was restarted. Uptime is low and the error log shows a shutdown or a signal.
• A slow query exceeded net_read_timeout or net_write_timeout while data was still moving.
• A connection pool handed out a stale connection that the server had already closed (common with long lived app processes).
• On managed MySQL such as Amazon RDS or Aurora, a failover or maintenance event repointed the endpoint and terminated existing connections.

How to fix it

Stabilize

1. Confirm whether the server is even up and how long it has been running. Low uptime means it restarted:

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

2. If the server just restarted, stop retrying blindly. Restarting apps into a database that is still recovering only compounds the incident.

Diagnose

1. Read the current limits so you know what you are working with:

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

2. Read the MySQL error log. Location varies by install, so ask the server:

SHOW GLOBAL VARIABLES LIKE 'log_error';

sudo tail -n 100 /var/log/mysql/error.log

On RDS, read the error log and recent events from the console or with the AWS CLI:

aws rds describe-events --source-identifier your-db-instance --source-type db-instance

3. Match the evidence to a cause. Error near a large statement points at max_allowed_packet. Error after idle time points at wait_timeout. Low uptime or a shutdown line in the log points at a crash or restart. A slow query that dies mid transfer points at the net_* timeouts.

Fix

1. If packets are too small, raise max_allowed_packet on both server and client. Set it on the running server, then persist it in the config file so it survives a restart:

SET GLOBAL max_allowed_packet = 67108864;

[mysqld]
max_allowed_packet = 64M

The client must also allow the larger packet. With the CLI: mysql --max-allowed-packet=64M. Note that existing connections keep the old value, so reconnect after changing it.

2. If idle connections are being closed, do not simply set wait_timeout to an enormous value. Instead, keep it reasonable and fix the application side. Enable connection validation in your pool so dead connections are discarded before use:

   • HikariCP: set a maxLifetime shorter than wait_timeout.
   • SQLAlchemy: set pool_pre_ping=True and a pool_recycle below wait_timeout.
   • PHP PDO: reconnect on failure rather than holding a long lived handle.

3. If the server crashed or was OOM killed, treat the memory pressure as the real problem. Check innodb_buffer_pool_size against available RAM and review the host memory and swap. Fixing 2006 without fixing the cause of the crash just delays the next one.

4. For slow query failures, optimize the query or raise net_read_timeout and net_write_timeout deliberately, not reflexively.

How to prevent it

• Match max_allowed_packet across server and every client, sized to your largest legitimate payload.
• Use connection pool validation everywhere: test on borrow, pre-ping, and a maxLifetime or pool_recycle shorter than the server wait_timeout.
• Monitor Uptime and Aborted_clients so restarts and abrupt disconnects are visible before users report them.
• On RDS or Aurora, design the app to reconnect cleanly on failover and keep pool lifetimes short.
• Alert on host memory so an OOM kill is caught as memory pressure, not as a mystery database outage.

When to call a senior engineer

Bring in help when the error log shows repeated crashes or OOM kills, when a production database is flapping under load, or when 2006 appears intermittently across services and you cannot isolate the cause. If the incident is live and customers are affected, a second set of experienced eyes on the error log and the pool configuration will resolve it faster than trial and error against production.