How to Fix “MySQL Server Has Gone Away” (Error 2006)

Encountering “Error 2006 (HY000): MySQL server has gone away” means that a client application (such as WordPress, Laravel, or a backup import script) was actively communicating with the database, but the MySQL server abruptly closed or terminated the connection.

This error is misleading: it does not always mean the database server is completely offline. In most production environments, it means the server dropped an individual connection because the query packet was too large, an idle connection timed out, or the MySQL daemon crashed during query execution.

Quick Answer

If the error occurs during database imports or large data saves, increase max_allowed_packet in /etc/mysql/my.cnf:
```
[mysqld]
max_allowed_packet = 128M
wait_timeout = 600
interactive_timeout = 600
```

Restart MySQL or MariaDB:

sudo systemctl restart mysql || sudo systemctl restart mariadb

If the error occurs at random times, inspect the error log to see if the database daemon is crashing from Out of Memory (OOM) events:
```
tail -n 50 /var/log/mysql/error.log
```

Symptoms

Web applications display: “SQLSTATE[HY000] [2006] MySQL server has gone away”.
Database imports fail halfway through with: “ERROR 2006 (HY000) at line XXX: MySQL server has gone away”.
Background workers (Laravel queues, Celery, or WordPress cron jobs) crash after sitting idle for several minutes.
Application logs show connection drops specifically during large file uploads, serialized data saves, or complex SQL queries.

Common Causes

max_allowed_packet Exceeded: The client attempted to send a query or insert an object (like a high-res image, PDF, or serialized cache) that exceeds the server’s configured packet limit. MySQL instantly closes the connection.
Idle Connection Timeout (wait_timeout): A persistent application worker opened a database connection, performed other long-running tasks for 10 minutes, and tried to reuse the connection after MySQL had already closed it.
MySQL Daemon Crash (OOM Killer): The MySQL service ran out of memory while executing a heavy query and was terminated by the Linux kernel.
Dropped TCP Socket: A firewall or load balancer between the application server and the database server dropped an inactive connection state.
Slow Query Forced Termination: A query exceeded server execution limits or was killed by an administrator via KILL <thread_id>.

Before You Start

Check whether MySQL is actually running or if it restarted recently:
```
mysqladmin -u root -p status
```
Look at the Uptime counter. If the uptime is only a few seconds or minutes, MySQL crashed and restarted.
Always backup your database configuration (my.cnf) before applying changes.
For enterprise database optimization, consult our server performance optimization engineers.

Step 1 — Check MySQL Crash Logs and Systemd Uptime

First determine whether the entire MySQL server crashed, or if only a single client connection was dropped.

Run systemctl status:

systemctl status mysql || systemctl status mariadb

Look at the active duration:

Active: active (running) since Fri 2026-09-18 14:30:15 UTC; 42s ago

If the database restarted less than a minute ago, check /var/log/mysql/error.log (or dmesg) for kernel crashes:

dmesg -T | grep -i -E "oom|killed process|mysqld"

If the kernel killed mysqld due to RAM starvation, add swap space or tune innodb_buffer_pool_size so MySQL does not exceed available system memory.

Step 2 — Increase max_allowed_packet

If the MySQL server did not crash and the error happens during large data imports, form submissions, or backup restorations, the query size exceeded max_allowed_packet.

Check your current live packet size:

mysql -e "SHOW VARIABLES LIKE 'max_allowed_packet';"

The default is often 16MB (16777216 bytes) or even 4MB on older distributions.

Update Configuration File

Open /etc/mysql/my.cnf (or /etc/mysql/mysql.conf.d/mysqld.cnf or /etc/my.cnf):

sudo nano /etc/mysql/my.cnf

Under the [mysqld] section, set:

[mysqld]
max_allowed_packet = 128M

Also add it to the [mysqldump] and [client] sections so import utilities like mysql and mysqldump can handle large packets:

[client]
max_allowed_packet = 128M

[mysqldump]
max_allowed_packet = 128M

Save the file and restart MySQL:

sudo systemctl restart mysql || sudo systemctl restart mariadb

Verify that the new 128MB setting is active:

mysql -e "SHOW VARIABLES LIKE 'max_allowed_packet';"

Step 3 — Increase Connection Timeouts (wait_timeout)

If the error occurs in background workers or cron scripts that remain idle between operations, MySQL’s wait_timeout has disconnected the sleeping client.

Check current timeout variables:

mysql -e "SHOW VARIABLES LIKE '%timeout%';" | grep -E "wait_timeout|interactive_timeout|net_read_timeout|net_write_timeout"

Sample Default Values

wait_timeout: 28800 (8 hours) or lowered to 60 on heavily tuned hosting servers.
net_read_timeout: 30 seconds.
net_write_timeout: 60 seconds.

Update my.cnf for Reliable Background Workloads

Add or adjust these parameters in /etc/mysql/my.cnf:

[mysqld]
wait_timeout = 600
interactive_timeout = 600
net_read_timeout = 120
net_write_timeout = 120

wait_timeout = 600: Gives idle threads up to 10 minutes before closing the socket.
net_read_timeout = 120: Gives slow network connections up to 2 minutes to send query data.

Restart MySQL to apply changes.

Step 4 — Handle Error 2006 During mysqldump Import

If you are restoring a large .sql backup file and it crashes with Error 2006, override the packet limit directly on the command line during import:

mysql --max_allowed_packet=512M -u root -p target_database < backup_dump.sql

This bypasses any client-side packet constraints without requiring a server reboot.

Step 5 — Verify Application Connection Health

Test whether your application can maintain active queries without drops.

Run an extended test query via Bash:

mysql -e "SELECT SLEEP(15);"

If the query returns after 15 seconds with value 0, MySQL successfully maintained the thread without disconnecting.

Monitor your MySQL error log in real time during application testing:

tail -f /var/log/mysql/error.log

Common Mistakes

Editing the wrong my.cnf file: Linux distributions often have multiple configuration files (/etc/my.cnf, /etc/mysql/my.cnf, /etc/mysql/conf.d/). Verify which files are loaded using mysqld --help --verbose | grep -A 1 "Default options".
Setting max_allowed_packet above 1GB: The absolute maximum supported by MySQL is 1GB (1024M). Allocating excessively huge values wastes buffer memory on low-RAM VPS servers.
Failing to close idle connections in application code: Writing scripts that open a persistent MySQL connection and sleep for 30 minutes without pinging the server ($pdo->query("SELECT 1") or auto-reconnect logic).

Prevention Checklist

Set max_allowed_packet to at least 64M or 128M for content management systems.
Implement database connection health checks and automatic reconnection in long-running worker processes.
Monitor MySQL memory footprint against total system RAM.
Review our server performance optimization services to tune InnoDB buffer pools and transaction log files.

Quick Reference Variables

Variable	Recommended Production Value	Purpose
`max_allowed_packet`	`128M`	Maximum size of an individual SQL query or data row
`wait_timeout`	`600` (10 mins)	Time MySQL waits for activity on an idle connection
`interactive_timeout`	`600`	Timeout for interactive client connections (mysql CLI)
`net_read_timeout`	`120`	Timeout for waiting for more data from a client
`net_write_timeout`	`120`	Timeout for waiting for a client to accept a response

Frequently Asked Questions

Does “MySQL server has gone away” mean the database crashed?

Not necessarily. In the majority of cases, the MySQL daemon remains running, but it closed the specific client connection because the query exceeded max_allowed_packet or the connection sat idle past wait_timeout.

Can a slow network connection cause Error 2006?

Yes. If your application server connects to a remote database server across regions or over a VPN, high packet loss or network latency can cause the connection to drop while waiting for query transmission. Increasing net_read_timeout and net_write_timeout mitigates this.

Why do I get Error 2006 when importing a WordPress database?

WordPress stores post revisions, serialized theme options, and transient caches in large database rows. When mysqldump generates an INSERT statement containing hundreds of rows, the statement easily exceeds a default 16MB packet limit.

How does ServerCare360 assist with MySQL database reliability?

Our server performance optimization and emergency server support specialists tune MySQL configurations, configure automated query caching, resolve OOM crashes, and maintain 24/7 database cluster health.