Error 2006: MySQL Server Has Gone Away

MySQL error 2006: Server has gone away means the following - the client has lost its connection to the MySQL or MariaDB server. The cause often hides in a large SQL query or a dump. Sometimes this happens because the server itself was restarted, or during network issues.

But this error by itself doesn't always mean critical problems, such as database corruption or a broken MySQL installation. Most often, the situation is much simpler and looks like this: the connection is closed, while the application or client tries to keep interacting with it. The result of this failed interaction is precisely the MySQL 2006: Server has gone away error.

What error 2006 means and when it occurs

In this situation, code 2006 corresponds to the client error CR_SERVER_GONE_ERROR — MySQL server has gone away. The error appears only when the client can't send a query through an existing connection to the MySQL server.

The related error 2013 (Lost connection to MySQL server during query) occurs when the connection is lost directly while a query is being executed. Speaking of practical situations, several common cases of error 2006 can be highlighted:

• during the import of a large SQL dump;

• while running a large INSERT, especially one with many rows;

• in a PHP application after a long idle period on the connection;

• in the MySQL CLI client;

• when working with large BLOBs or other bulky data;

• after mysqld/mariadbd restarts or crashes;

• with an unstable remote connection to the database.

The tricky part is that there's no universal setting that can fix all these issues at once. So you need to approach it like this - first figure out the cause of this behavior, then choose the most effective way to resolve it. The key task at this stage is to pinpoint exactly when the connection drop happens.

Cause 1 — the connection timeout expired

This is probably the most common cause - the server simply closes an inactive connection due to wait_timeout. This variable sets the number of seconds MySQL is willing to wait for activity from a regular client connection before closing it.

Interactive connections typically use the related interactive_timeout setting. Values can be set globally and per individual session. So if an application established a connection to MySQL, ran a query, and then sat idle for a long time, the error appears.

It also happens that a connection stays open longer than it should. In that case, the server follows the configured rule and simply closes the connection once it exceeds the time limit. After the connection is closed, the application tries to use it again, and the result of that attempt is the MySQL server has gone away error.

So let's check the settings:

SHOW VARIABLES LIKE '%timeout%';

More specifically:

SHOW VARIABLES LIKE 'wait_timeout';
SHOW VARIABLES LIKE 'interactive_timeout';

In MySQL 8.4, "wait_timeout" is a dynamic variable, so its global value can be changed without a restart:

SET GLOBAL wait_timeout = 28800;
SET GLOBAL interactive_timeout = 28800;

One nuance: changing the GLOBAL value doesn't override the value already set in existing sessions. New connections will get the new global value.

For a permanent change, add the parameter to the server configuration:

[mysqld]
wait_timeout = 28800
interactive_timeout = 28800

After changing the configuration, restart the MySQL/MariaDB service.

And here it's important not to make a common mistake - many users just crank the value up to the maximum without thinking twice. Don't do that, because the application may be mismanaging connections, and a longer timeout will only mask the problem. This leads to an accumulation of long-lived connections.

A VPS is a great fit for solving this problem. The beauty of it is the ability to control the MySQL/MariaDB configuration on your VPS yourself: server parameters aren't limited by shared hosting restrictions.

If you need to find out which option files your installed MySQL is actually using, you can check:

mysqld --verbose --help 2>/dev/null | grep -A 1 "Default options"

For MariaDB:

mariadbd --verbose --help 2>/dev/null | grep -A 1 "Default options"

Let's move to the next cause.

Cause 2 — max_allowed_packet exceeded

Sometimes a user tries to import a dump or run a large SQL query, and that's exactly when the error pops up. If that's your case, the first thing we recommend checking is max_allowed_packet.

The thing is, this parameter limits the maximum size of a single data packet that MySQL can process. The problem is especially relevant for:

• large SQL dumps;

• huge "INSERT" statements;

• large "BLOB" values;

• long strings;

• bulk insertion of large amounts of data in a single query.

Once the error appears, be sure to check the value with the command:

SHOW VARIABLES LIKE 'max_allowed_packet';

In MySQL 8.4 the variable is dynamic:

SET GLOBAL max_allowed_packet = 134217728;

Where "134217728" bytes equals 128 MiB.

In MySQL, an oversized data packet is one of the most frequent causes of MySQL 2006: Server has gone away. What should you do in this situation? Increase the limit? That's one option, but be sure to account for the available memory and the size of the query. The query needs to fully match both of these values.

An important point - MySQL notes that the client may have its own max_allowed_packet limit; for example, the CLI client gets its value via a command-line option. Keep this in mind when changing the global value.

When importing a dump, use:

mysql --max-allowed-packet=128M -u USER -p DATABASE < dump.sql

When connecting to a remote server:

mysql -h SERVER_IP --max-allowed-packet=128M -u USER -p DATABASE < dump.sql

In the server configuration, the parameter is set in the [mysqld] section:

[mysqld]

max_allowed_packet = 128M

Users often ask - "what value should I set?". There's no one-size-fits-all recommendation here. Base it on your specific situation. For example, if your dump contains queries totaling 50 MB, set the limit above that value - say, 60 MB. Just set the limit above the dump size, but don't set it to the maximum possible value.

It's a mistake to think of max_allowed_packet as a free setting with no tradeoffs. Overly aggressive values combined with many simultaneous connections lead to increased memory consumption. As for MariaDB, max_allowed_packet is a dynamic global variable there too, and the maximum value is 1 GB. When changing the server-side value, MariaDB recommends taking the client-side value into account as well.

Cause 3 — the MySQL/MariaDB process crashed or was restarted

If the server stopped working, causing the MySQL/MariaDB process to crash, the MySQL 2006: Server has gone away error will also appear. And this is where you need to dig into the cause of such behavior carefully. It's usually one of the following:

• insufficient RAM;

• the Linux OOM killer;

• a server-side bug;

• corruption or an issue with a specific query;

• a manual restart;

• package updates;

• an abnormal process termination.

There's no point checking wait_timeout or max_allowed_packet here. The first thing you need to do in this situation is make sure the server hasn't crashed. When the server crashes, the old connection becomes invalid. A client that keeps using it will get error 2006.

Under systemd, check the log:

sudo journalctl -u mysql --since "1 hour ago"

For MariaDB:

sudo journalctl -u mariadb --since "1 hour ago"

Check the kernel messages related to memory shortage:

sudo dmesg -T | grep -i -E 'oom|out of memory|killed process'

Or:

sudo journalctl -k | grep -i -E 'oom|out of memory|killed process'

It also wouldn't hurt to check the MySQL/MariaDB error log. Many people manage to find the actual cause right there. For instance, mysqld crashes due to a lack of memory, and increasing max_allowed_packet doesn't fix the issue - in fact, it makes it worse. The root cause isn't a single parameter, but a shortage of resources for the current load.

For a VPS, this is an important point: if the server is constantly short on RAM, it makes more sense to consider a plan with more memory than to endlessly tweak individual MySQL parameters.

Cause 4 — network disruption or infrastructure limitations

When connecting to the database from a different server, you run the risk of seeing the MySQL 2006: Server has gone away message.

This is especially relevant for an architecture like:

Application – internet – firewall – VPS – MySQL

In this situation, MySQL itself works fine, but one of the intermediate components closes an idle TCP connection. The connection to the database can simply be interrupted by one of the following participants:

• a firewall;

• NAT;

• a network failure;

• an unstable remote connection;

• DNS issues;

• client-side read/write timeouts.

MySQL's documentation separately mentions TCP/IP timeouts and network issues among the possible causes of connection loss. When the database is on a different server, it's useful to test the connection directly from the application's machine:

mysql -h SERVER_IP -u USER -p

Does the connection keep dropping even on small queries? Increasing max_allowed_packet won't help here - you need to look for the problem at the network level.

How to quickly identify your specific cause

It also wouldn't hurt to check how long MySQL itself has been running:

SHOW GLOBAL STATUS LIKE 'Uptime';

If Uptime is unexpectedly small, the server was recently restarted.

How to prevent this error in the future

There's no universal method - when the error occurs, you need to dig into the specific situation. But there are simple yet very effective recommendations you can use to reduce the risk, or rule out entirely, the chance of MySQL 2006: Server has gone away happening in the future.

Add proper reconnect logic

An application shouldn't treat an open connection as eternal. After a long idle period, the connection might have been closed by the server or by the infrastructure. Depending on the driver being used, the application should be able to detect the drop and correctly establish a new connection. MySQL also recommends checking the connection, for example via mysql_ping(), if a long time passes between queries.

Keep an eye on RAM

If MySQL keeps restarting regularly, first look for the cause in the logs and the state of your RAM. Pay particular attention to memory usage when simultaneously dealing with:

• a large InnoDB buffer pool;

• a large number of connections;

• heavy queries;

• temporary tables;

• large imports.

Don't over-inflate max_allowed_packet

Increase the parameter to fit the specific task at hand. If the problem occurs during a dump import, first determine the size of your largest queries. Then set a reasonable margin above that. 1 GB isn't automatically the best value. The higher the limit, the larger the potential amount of memory that may be needed to process oversized packets. Think of this setting as a trade-off between your application's requirements and the resources available.

Don't increase timeouts without a good reason

If the application keeps connections open for hours, increasing wait_timeout may just mask a connection management problem. It's better to configure the application so that it:

• closes connections it no longer needs;

• uses connection pooling where appropriate;

• reconnects properly when needed;

• doesn't run huge operations in a single query unless truly necessary.

Conclusion

MySQL 2006 Server has gone away doesn't mean your database is broken. In most cases, it's the result of a specific event: the server closed an inactive connection, the query was too large, MySQL restarted, or the connection was lost over the network. In such situations, you need to act in a targeted way - first identify the cause of the problem, and only then work on fixing it.

The optimal diagnostic order looks like this:

1. Identify the exact moment the error occurs.

2. Check the timeouts.

3. Check max_allowed_packet.

4. Check whether MySQL has restarted.

5. Check RAM and OOM events.

6. Check the network.

If it turns out that the error is caused by a persistent lack of RAM for your current database and workload, it's worth considering a VPS with more resources. On a VPS from Leneex, you can manage the MySQL/MariaDB configuration yourself and tailor the server parameters to your specific application, without the typical limitations of shared hosting.