MySQL Server Has Gone Away

What error 2006 means

Error 2006 means the client's connection to MySQL died before a reply arrived. Read the timing first: a drop during a large import points at max_allowed_packet, an idle gap points at wait_timeout, and every connection dying at once means the server restarted or was killed.

The message is the same in a PHP page, a phpMyAdmin import and a command-line mysql session. What differs is where the fault sits, so the error alone cannot tell you what to change. The log line around it can.

• One query dies, everything else works: the packet was too large, or the query ran too long.
• A connection that sat unused dies on its first query: the server closed an idle connection.
• Every page fails at the same second: MySQL stopped, crashed, or was killed for memory.
• It happens only during imports or backups: packet size, not timeout.

Find which cause you have before you edit anything

Match the pattern first. Each cause has a different fix, and raising the wrong variable wastes an hour.

Run those queries in phpMyAdmin's SQL tab or in a mysql shell. Both read the same server variables, so the answer is identical either way.

max_allowed_packet is smaller than the query

One packet has a ceiling. A multi-row INSERT from a dump, a LONGTEXT column, or a base64 blob can cross it, and the server closes the connection rather than half-apply the statement.

1. Read the current value with SHOW VARIABLES LIKE 'max_allowed_packet';. Defaults are 64 MB on MySQL 8 and 16 MB on MariaDB 10.4 and later.
2. Set it for the running server with SET GLOBAL max_allowed_packet = 268435456; for 256 MB. New connections pick it up; existing ones do not.
3. Make it permanent in my.cnf under [mysqld]: max_allowed_packet=256M. Add the same line under [client] so the client agrees.
4. Restart with systemctl restart mysql. You know it worked when SHOW VARIABLES reports 268435456 after the restart.

You do not need a restart for an import. Pass the value on the command itself instead: mysql --max_allowed_packet=256M dbname < dump.sql. That flag applies to the client that sends the packets, which is where the limit is hit.

wait_timeout closed an idle connection

wait_timeout is how long the server keeps a quiet connection before closing it. The MySQL default is 28800 seconds, eight hours, but shared hosts often set it to 60 or 90 to free memory.

1. Read it with SHOW VARIABLES LIKE 'wait_timeout'; and the same for interactive_timeout.
2. If the value is under 120 seconds and your application keeps connections open between requests, raise it: SET GLOBAL wait_timeout = 300;.
3. Persist it in my.cnf under [mysqld] as wait_timeout=300, then restart.
4. Check the application side too. PHP's default_socket_timeout and mysql.connect_timeout should not be shorter than the server's wait_timeout, or the client gives up first.

A better fix than a longer timeout is a shorter connection: reconnect before each batch of work, or use a connection pool that checks the link before reusing it. Idle connections held open all night are what created the problem.

The server restarted or was killed

When every connection drops at the same moment, the server died. That is a hosting problem, not a query problem, and no setting in your application will fix it.

1. Run mysqladmin version and read Uptime. Minutes of uptime mean mysqld restarted; days mean it did not.
2. Open the error log, usually /var/log/mysql/error.log or /var/log/mysqld.log, and read the lines around the failure time.
3. Search for Killed or oom-kill in dmesg -T. That names the Linux OOM killer, which takes mysqld when RAM runs out.
4. On a VPS you control, lower innodb_buffer_pool_size to about half the RAM, stop competing services, then restart. On shared hosting, send the timestamp to support instead.

A single crashed table can also look like this, because the query stalls and the connection times out. CHECK TABLE name; and REPAIR TABLE name; will tell you, and an InnoDB table usually recovers on its own at startup.

Large imports and dumps that trip the ceiling

A restore is the most common place to meet error 2006, because a dump sends thousands of statements as fast as the pipe allows. Three flags make it survive.

• --max_allowed_packet=256M on both mysqldump and mysql, so neither side refuses the other's packets.
• --net_buffer_length=16384 lowers the size of each statement the client builds, which helps on a host where you cannot raise the server value.
• --single-transaction on the dump, so the export is consistent without locking tables during the copy.

If the server value cannot be changed at all, split the dump by table and import one file at a time: mysqldump dbname table_name > table.sql, then mysql dbname < table.sql. A large table can be split further with --where="id BETWEEN 1 AND 100000".

Fixing it from cPanel when there is no my.cnf

Shared hosting does not give you the server configuration file, so the server-wide values are fixed. Work within them.

• Import through phpMyAdmin in smaller files, or use the cPanel Terminal and the mysql client with the per-command flag.
• Raise PHP's limits first, because a PHP timeout produces a similar failure: upload_max_filesize, post_max_size, max_execution_time and memory_limit in MultiPHP INI Editor.
• Ask support for the current max_allowed_packet and wait_timeout values rather than guessing them.

The cPanel database workflow covers creating a user, granting privileges and importing through the panel. If the error mentions a lost connection during a query rather than during an import, the database connection error guide covers the credentials and socket cases.

When to email support instead of editing settings

Email support@webji.services with the exact error line, the timestamp, and the query or import that triggered it. Add the output of mysqladmin version if you can run it. Support is 24/7 by email in Hindi and English, and the average first reply is under 60 minutes.

Do not call the office phone for a database outage; it is a business-hours line, not a support queue. On a VPS where you control my.cnf, VPS hosting plans include root access, and the same email address can size the RAM against your buffer pool.