Rare reasons for MySQL server has gone away error - mysql

I have checked the answers at MySQL error 2006: mysql server has gone away None of them seem to fit my problem.
I am getting the error MySQL server has gone away frequently.
It is not the connection timeout. The default timeout of 8 hours seems plenty.
I have tried upping the max_allowed_packet to no avail. This then seemed irrelevant when I began printing out the offending SQL statement which was in my case: SELECT url FROM crawled WHERE frontier = 1 ORDER BY id. Hardly a large statement which warrants upping max_allowed_packet.
So, none of the given answers seem to fit my scenario. Any other reasons why this error may occur? Any possible fixes?

Two common possibilities come to mind:
1) Out Of Memory error. Check syslog for evidence of it.
2) Bug or some other crash in mysqld thread. Check your MySQL error log.
The "server has gone away" almost always means a back end thread crash. And that should leave something obvious in the logs.

Related

MySQL server overloading

I have a MySQL server that is hosting my website. Yesterday, after trying to empty a certain database, I started receiving the following error when attempting to connect to my site :
PDOException: SQLSTATE[HY000] [1040] Too many connections in lock_may_be_available()
(line 167 of /home/vksappc/public_html/prod/includes/lock.inc).
After searching online for a possible solution, I restarted the server and everything was okay. Today, however, I've noticed that the number of active connections is constantly and slowly rising until it reaches the limit of 151 :
Screenshot of thread count
At which point the server then seems to timeout those connections and everything resets, only to start its gradual climb all over again:
Screenshot of new thread count
This is really becoming a big problem and as I am quite new to managing a server, I am not too sure what could be causing this or what to do next.
Any ideas?
Turns out there was a specific connection that was stuck in a loop of sending a request unsuccessfully and trying over and over again. Once we found which connection it was, we were able to kill all its processes and fix the issue. Thanks to #WilsonHauck for the tip in the comments.

Google MySQL fails with ERROR 2013 HY000 system error 2

I have a D8 google mysql instance. I'm running an etl process trying to push about 100GB of data in but the script keep stopping because of the error.
In order to get it working I have to restart the mysql instance and then re run the process from where it failed. Any help is greatly appreciated. I haven't found anything on google.
This error tends to mean the connection to the MySQL server was lost at some point. As mentioned in this 'Lost connection to MySQL server' article, this error may be encountered when writing a significant number or rows.
The article suggests setting the net_read_timeout to something greater than the default value of 30 seconds. You may also want to consider breaking up your write tasks as well.

MySQL Query running even after losing connection

I've a MySQL 5.1.41 Server installed on a Ubuntu machine. I get connected to it through Workbench from my Windows machine over TCP/IP. I run a bigger query, after 900 seconds I got the below message, (there is no wait_timeout defined in the server's configuration file my.cnf)
Error Code: 2013. Lost connection to MySQL server during query
But when I look into the process list by using show processlist; command, I can still see my query running.
I got this link http://dev.mysql.com/doc/refman/5.0/en/gone-away.html where I found the below lines,
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.
I'm not sure whether this is the reason for my observation.
Please clarify me on this.
Thanks in advance!!
Closing connection is not a reason to stop a query. A query might be update, or kind of transaction, or select with output to remote (server) file.
Closed connection is just is just means, that you will not receive any data from DBMS after executing query (data, timings - nothing).
The reason of closing connection could be different, as SO-User posted. Try increasing
on server side:
wait_timeout
max_allowed_packet
on client side:
any kinds of timeout you find in your client (i.e. that SO-User suggests)
Do not forget to reload DBMS config and restart client (for sure)
In MySQL WorkBench we have an option to change timeout.
Find it under
Edit → Preferences → SQL Editor → DBMS connection read time out (in seconds): 600
Changed the value to 6000 or something higher.
Update
Lost connection to MySQL server
There are three likely causes for this error message.
Usually it indicates network connectivity trouble and you should check
the condition of your network if this error occurs frequently. If the
error message includes “during query,” this is probably the case you
are experiencing.
Sometimes the “during query” form happens when millions of rows are
being sent as part of one or more queries. If you know that this is
happening, you should try increasing net_read_timeout from its default
of 30 seconds to 60 seconds or longer, sufficient for the data
transfer to complete.
More rarely, it can happen when the client is attempting the initial
connection to the server. In this case, if your connect_timeout value
is set to only a few seconds, you may be able to resolve the problem
by increasing it to ten seconds, perhaps more if you have a very long
distance or slow connection. You can determine whether you are
experiencing this more uncommon cause by using SHOW GLOBAL STATUS LIKE
'Aborted_connects'. It will increase by one for each initial
connection attempt that the server aborts. You may see “reading
authorization packet” as part of the error message; if so, that also
suggests that this is the solution that you need.
If the cause is none of those just described, you may be experiencing
a problem with BLOB values that are larger than max_allowed_packet,
which can cause this error with some clients. Sometime you may see an
ER_NET_PACKET_TOO_LARGE error, and that confirms that you need to
increase max_allowed_packet.
Doc link: Error lost connection
and also check here

how to understand "can't connect" mysql error messages?

I have the following error message:
SQLSTATE[HY000] [2003] Can't connect to MySQL server on
'192.168.50.45' (4)
How would I parse this (I have HY000, I have 2003 and I have the (4).
HY000 is a very general ODBC-level error code, and 2003 is the MySQL-specific error code that means that the initial server connection failed. 4 is the error code from the failed OS-level call that the MySQL driver tried to make. (For example, on Linux you will see "(111)" when the connection was refused, because the connect() call failed with the ECONNREFUSED error code, which has a value of 111.)
Using the perror tool that comes with MySQL:
shell> perror 4
OS error code 4: Interrupted system call
It might a bug where incorrect error is reported, in this case, it might a simple connection timeout (errno 111)
FWIW, having spent around 2-3 months looking into this in a variety of ways, we have come to the conclusion that (at least for us), the (4) error happen when the network is too full of data for the connection to complete in a sane amount of time. from our investigations, the (4) occurs midway through the handshaking process.
You can see this in a unix environment by using 'netem' to fake network congestion.
The quick solution is to up the connection timeout parameter. This will hide any (4) error, but may not be the solution to the issue.
The real solution is to see what is happeneing at the DB end at the time. If you are processing a lot of data when this happens, it may be a good ideas to see if you can split this into smaller chunks, or even pas the processing to a different server, if you have that luxury.
I happened to face this problem. Increase the connect_timeout worked out finally.
I was just struggling with the same issue.
Disable the DNS hostname lookups solved the issue for me.
[mysqld]
...
...
skip-name-resolve
Don't forget to restart MySQL to take effect.
#cdhowie While you may be right in other circumstances, with that particular error the (4) is a mysql client library error, caused by a failed handshake. Its actually visible in the source code. The normal reason is too much data causing an internal timeout. Making 'room' for the connection normally sorts it without masking the issue, like upping the timeout or increasing bandwidth.

Got an error reading communication packets in MySQL

I am getting the MySQL error
"Got an error reading communication packets"
in MySQL.err file and in my application side I am getting 2013 error (lost connection during query).
All the timeout values are (in seconds):
wait_timeout = 60
net_read_timeout = 30
connect_timeout = 30
How to resolve this?
For what this is worth, this vague error is somewhat common with many possible culprits.
Often it is not a problem with MySql per say...but the system or calling program instead. eg Sometimes you have php memory limits set to low or the swap drive was never setup...that crashes PHP and MySQL is left confused as to what happened.
In my case, I didn't have that, but I was trying to do a json_encode on a character string with non-utf8 characters which would fail silently and drag mysql down with it. On top of this OPCache in PHP7 seems to be seriously buggy and lacks proper error logging. I had to disable that as well...then magically all my problems with "communication packets" in /var/log/mysql/error.log went away.
Hope this helps someone...gave me a LOT of grief.
Another very weird corner case: check your RAM and your swap!
If you have not enough RAM and swap space, your operating system may decide to kill processes causing your exact error in case of MySQL (Got an error reading communication packets). This is a common situation in virtual machines where the provider often does not install any partition for the swap (and when often people does not pay enough RAM).
So, double-check with top or htop to verify if you have ~100% of your RAM in use or if you have not enough swap (or not swap space at all).
In that case, buy more RAM or search "how to install swapfile" in your distribution.
If that's not the case, see the other answers. Cheers! :)