Documentation Home
MySQL 5.7 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 37.4Mb
PDF (A4) - 37.4Mb
PDF (RPM) - 36.8Mb
HTML Download (TGZ) - 10.2Mb
HTML Download (Zip) - 10.2Mb
HTML Download (RPM) - 8.8Mb
Man Pages (TGZ) - 210.2Kb
Man Pages (Zip) - 318.3Kb
Info (Gzip) - 3.4Mb
Info (Zip) - 3.4Mb
Excerpts from this Manual

B.5.2.9 MySQL server has gone away

This section also covers the related Lost connection to server during query error.

The most common reason for the MySQL server has gone away error is that the server timed out and closed the connection. In this case, you normally get one of the following error codes (which one you get is operating system-dependent).

Error CodeDescription
CR_SERVER_GONE_ERRORThe client couldn't send a question to the server.
CR_SERVER_LOSTThe client didn't get an error when writing to the server, but it didn't get a full answer (or any answer) to the question.

By default, the server closes the connection after eight hours if nothing has happened. You can change the time limit by setting the wait_timeout variable when you start mysqld. See Section 6.1.5, “Server System Variables”.

If you have a script, you just have to issue the query again for the client to do an automatic reconnection. This assumes that you have automatic reconnection in the client enabled (which is the default for the mysql command-line client).

Some other common reasons for the MySQL server has gone away error are:

  • You (or the db administrator) has killed the running thread with a KILL statement or a mysqladmin kill command.

  • You tried to run a query after closing the connection to the server. This indicates a logic error in the application that should be corrected.

  • A client application running on a different host does not have the necessary privileges to connect to the MySQL server from that host.

  • You got a timeout from the TCP/IP connection on the client side. This may happen if you have been using the commands: mysql_options(..., MYSQL_OPT_READ_TIMEOUT,...) or mysql_options(..., MYSQL_OPT_WRITE_TIMEOUT,...). In this case increasing the timeout may help solve the problem.

  • You have encountered a timeout on the server side and the automatic reconnection in the client is disabled (the reconnect flag in the MYSQL structure is equal to 0).

  • You are using a Windows client and the server had dropped the connection (probably because wait_timeout expired) before the command was issued.

    The problem on Windows is that in some cases MySQL does not get an error from the OS when writing to the TCP/IP connection to the server, but instead gets the error when trying to read the answer from the connection.

    The solution to this is to either do a mysql_ping() on the connection if there has been a long time since the last query (this is what Connector/ODBC does) or set wait_timeout on the mysqld server so high that it in practice never times out.

  • You can also get these errors if you send a query to the server that is incorrect or too large. If mysqld receives a packet that is too large or out of order, it assumes that something has gone wrong with the client and closes the connection. If you need big queries (for example, if you are working with big BLOB columns), you can increase the query limit by setting the server's max_allowed_packet variable, which has a default value of 4MB. You may also need to increase the maximum packet size on the client end. More information on setting the packet size is given in Section B.5.2.10, “Packet Too Large”.

    An INSERT or REPLACE statement that inserts a great many rows can also cause these sorts of errors. Either one of these statements sends a single request to the server irrespective of the number of rows to be inserted; thus, you can often avoid the error by reducing the number of rows sent per INSERT or REPLACE.

  • You also get a lost connection if you are sending a packet 16MB or larger if your client is older than 4.0.8 and your server is 4.0.8 and above, or the other way around.

  • It is also possible to see this error if host name lookups fail (for example, if the DNS server on which your server or network relies goes down). This is because MySQL is dependent on the host system for name resolution, but has no way of knowing whether it is working—from MySQL's point of view the problem is indistinguishable from any other network timeout.

    You may also see the MySQL server has gone away error if MySQL is started with the --skip-networking option.

    Another networking issue that can cause this error occurs if the MySQL port (default 3306) is blocked by your firewall, thus preventing any connections at all to the MySQL server.

  • You can also encounter this error with applications that fork child processes, all of which try to use the same connection to the MySQL server. This can be avoided by using a separate connection for each child process.

  • You have encountered a bug where the server died while executing the query.

You can check whether the MySQL server died and restarted by executing mysqladmin version and examining the server's uptime. If the client connection was broken because mysqld crashed and restarted, you should concentrate on finding the reason for the crash. Start by checking whether issuing the query again kills the server again. See Section B.5.3.3, “What to Do If MySQL Keeps Crashing”.

You can get more information about the lost connections by starting mysqld with the log_error_verbosity system variable set to 3. This logs some of the disconnection messages in the hostname.err file. See Section 6.4.2, “The Error Log”.

If you want to create a bug report regarding this problem, be sure that you include the following information:

See also Section B.5.2.11, “Communication Errors and Aborted Connections”, and Section 1.7, “How to Report Bugs or Problems”.

User Comments
  Posted by Devin Henderson on July 3, 2007
Like myself, you might be getting this bug because you have failed to properly upgrade from MySQL 4 to MySQL 5. Make sure you have run the 'mysql_upgrade' command:

For reference also see:
  Posted by Martin Mokrejs on April 28, 2008
This also happens when you use compression of the mysql connection handler and due to some limitations of mysql server which cannot return easily an error message. Instead, it just kills the connection without a message. So turn off the compression and remove the 'quick' option from /etc/my.cnf if you observe lost connections to get the message.

Read the answer from Michael Widenius:

[19 Aug 2003 15:41] Michael Widenius

Sorry about the last bug entry, but it was not true. Sinisa had a patch pending but I
didn't approve of it as it didn't solve this problem for all cases.

This problem is already documented in the manual section
'MySQL server has gone away Error':

You can also get these errors if you send a query to the server that is
incorrect or too large. If mysqld gets a packet that is too large.
or out of order, it assumes that something has gone wrong with the client and
closes the connection.

We fixed this problem in 4.0 for not compressed packets but for
compressed packets it's VERY hard to fix it without having to allocate
a buffer bigger than max_allowed_packet, which would defeat the
purpose of this flag. Ane problem is that to be able to skip the
packet we have to decompress all packets in the stream and this would
make it easy for someone to force the server to allocate a lot of big
packets even if the MySQL administrator has forbidden this.

I looked into fixing this but didn't come up with a good way to to fix
it without a major amount of work (8-16 hours).

As we have more important things on our todo (this is not a serious
bug) we have to put this on hold for now and look at fixing this in
4.1 or 5.0.

The easy way to avoid this problem is to ensure that max_allowed_packet is set bigger in
the mysqld server than in the client and that all clients uses the same value for


and other reports:

  Posted by Angelo Mondati on September 1, 2008
Be aware of multi-threading.

I have used a c++ singleton class to encapsulate the mysql C API.
Using the same 'instance' of the class in two separate threads(or sharing the same mysql connection between threads), has raised this kind of errors (CR_SERVER_GONE_ERROR or CR_SERVER_LOST) when one thread ,which runs every 30 seconds, execute a query or a SQL command in the same time of the other thread.
  Posted by Paul Kenjora on May 8, 2009
I received this error when importing a mysqldump.

The simplest fix is to limit the packet size at export:

mysqldump somedb --max_allowed_packet=16 | gzip > /mnt/somedb.mysql.gz

Then on the import side ensure my.cnf [mysqld] has at least:

set-variable = max_allowed_packet=16M

If that doesn't work then try removing the extended inserts explicitly at dump...

mysqldump somedb --max_allowed_packet=16 --skip-extended-insert | gzip > /mnt/somedb.mysql.gz

Remember to restart your server using:

/sbin/service mysqld restart

  Posted by James R. on July 10, 2009
For all those having this problem and using PHP:

my problem was solved by downgrading PHP from 5.3.0 to 5.2.10.

Maybe it's the MySQL native driver in PHP not mature enough causing the problem.

I've tried all the solutions - to no avail - including:

-> setting up this options in my.ini/mysqld:


interactive_timeout = 28800


-> editing php.ini:

changing -> mysqli.reconnect = Off to On

-> checking all the versions of mysql I had available + mysql_upgrade

-> playing with php code:

forcing the connection to be closed after every query and reopening it immediately after that for the next query - this enabled forcing more queries to run but not all
  Posted by David Torre on September 26, 2009
Right after I upgraded to PHP 5.3 I started getting these "MySQL server has gone away" errors on almost every other page request from the apache server. I tried a few ideas that didn't work. Here is the solution: I changed all my mysql_pconnect() statements to mysql_connect(). It fixed the problem. For some reason PHP 5.3 DOES NOT LIKE persistent connections.
  Posted by Paul Purczel on June 22, 2010
I have had this problem for weeks, using a large query with joins. The way I managed to rectify the problem was not with the mysql settings, it was actually in php.ini
setting connect_timeout = 300
and default_socket_timeout = 300
they are set to default at 60 seconds and this caused my problem.
  Posted by Mike Kelly on March 17, 2011
I ran into this same error, and as a previous comment noted, and I think bears repeating, was eliminated when I stopped using persistent connections to connect to the MySQL database.
That is, I changed my "PDO::ATTR_PERSISTENT => true" settings to "PDO::ATTR_PERSISTENT => false" and the problem went away.
And there was great rejoicing.
  Posted by MySQL User on May 4, 2011
After I increased my max packet to 2000M, I watched htop when doing the sql import that kept failing and discovered the server went away when I ran out of ram and swap...
  Posted by Chris Calender on May 10, 2011
For those seeing this from PHP scripts, and you've already checked the other items listed above, then ensure your script is calling mysql_free_result when it completes.
  Posted by Jorge Torralba on June 2, 2011
I struggled with this all day. I was uploading two files and then inserting data into the table. The only difference with the files was their size. One would upload just fine and then the database update would take place using a prepared statement. All good. Then I would upload the other larger file which completed uploading but failed to update the database. In the end, what fixed my problem was setting mysqli.reconnect = On in php.ini. My only guess is that the larger file was taking longer to upload thus the db connection was timing out. As a side note, the file was NOT being stored in the db only info about the file.
  Posted by George Liu on August 27, 2011
Just a tip for WHM/Cpanel users experiencing this error it could be related to the WHM cronjob which runs during /scripts/upcp updates which updates WHM/Cpanel versions and checks for version updates to components such as MySQL server Solution is to change when that cronjob is run to not coincide with peak mysql activity time.

  Posted by Radu Onofrei on December 12, 2011
We have found that this problem may occur also because of a bad nameserver, or your own cpanel server listed into resolv.conf
  Posted by BOB GALLEY on March 9, 2012
goto include/local
if there is configure.php, delete this file.
  Posted by Pavel Bazanov on June 3, 2013
In my case the problem ("Lost connection to MySQL Server during query") was in a corrupted dump file or in the misbehaving HDDs:

First, I made a dump on the main server and then copied that dump to the replication server. But it seems the replication server had some problems with its HDDs and the dump became corrupted, i.e. MD5 of the original dump file on the main server was different from MD5 of the dump copy on the replication server.
  Posted by Bill Plimpton on August 7, 2013
The key of making it work from command line is not forgetting this part
max_allowed_packet = 1060M
  Posted by Anna Soseo on October 6, 2014
When you say : If you have a script, you just have to issue the query again for the client to do an automatic reconnection. This assumes that you have automatic reconnection in the client enabled
You can also put automatic reconnection on false to avoid server call. Anna from
  Posted by Isteak Ahamed on April 13, 2017
I am using laravel framework to create a project. It was running on nginx 1.12.0, Ubuntu 16.04

For me this problem was occurring when i tried to run the command 'php artisan migrate'

the problem was not with the max_allowed_packet, for me it was that i assigned wrong port in the laravel ".env" file.
The port needs to match with "my.cnf".
Sign Up Login You must be logged in to post a comment.