In MySQL error logs, I see these quite few a warnings like these:

120611 16:12:30 [Warning] Aborted connection 2619503 to db: 'db_name' user: 'user_name' host: 'webapp_hostname' (Got an error reading communication packets)

Haven't noticed any loss of data per se, so I am wondering what this warning means, or what causes it, and if how one might address the issue causing these. This is on RHEL 6.1 and MySQL Enterprise 5.5.


One of the silent killers of MySQL Connections is the MySQL Packet.

First, let's figure out what a MySQL Packet is.

According to the page 99 of "Understanding MySQL Internals" (ISBN 0-596-00957-7), here are paragraphs 1-3 explaining MySQL Packets:

MySQL network communication code was written under the assumption that queries are always reasonably short, and therefore can be sent to and processed by the server in one chunk, which is called a packet in MySQL terminology. The server allocates the memory for a temporary buffer to store the packet, and it requests enough to fit it entirely. This architecture requires a precaution to avoid having the server run out of memory---a cap on the size of the packet, which this option accomplishes.

The code of interest in relation to this option is found in sql/net_serv.cc. Take a look at my_net_read(), then follow the call to my_real_read() and pay particular attention to net_realloc().

This variable also limits the length of a result of many string functons. See sql/field.cc and sql/intem_strfunc.cc for details.

Knowing this about MySQL Packets allows a Developer/DBA to size them up to accommodate multiple BLOBs inside one packet even if they are obnoxiously large. Definitely, a packet too small will cause problems for open connections in this respect.

According to the MySQL Documentation

  • 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 1MB. 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 C.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.


Try raising the max_allowed_packet to a much larger number, since the default is 1M. I would suggest about 10 times the largest TEXT or BLOB field you have in your current dataset.

To set the max_allowed_packet to 256M, you can add it to /etc/my.cnf or my.ini


to cover future restarts of mysqld. To install the value now on the server, please run this:

SET GLOBAL max_allowed_packet = 1024 * 1024 * 256;

Give it a Try !!!

  • Very good explanation. – Vasilis Lourdas Jun 12 '12 at 19:50
  • 3
    @RolandoMySQLDBA I am still getting error in 5.7.28 after trying all mentioned solutions. Any tips to further troubleshoot – ImranRazaKhan Jan 18 '20 at 13:49

Mostly by default max_connections will be 100. Try increasing the config parameter

max_connections=400, after setting in my.cnf reboot the server, or set it dynamically :

    set @@global.max_connections = 400;

Just try the above recommendation to avoid this warning messages,and also ensure your network has no packet drops.


I encountered this issue recently after moving from MySQL Enterprise 5.1.x to 5.7.x, without any significant code changes to the application the 'note' started to appear.

In my case the root cause for the 'note' appearing was the program exiting with connections still open. The circumstance for connections not being closed were a little more involved and not related to MySQL but ACE, threads and TSS.


Not mentioned here so I am including another cause of this issue. In my case, while using the mysql command line client, the error was caused by a low value of 30 seconds of interactive_timeout:
This will persist across sessions but not a server restart.

SET GLOBAL interactive_timeout=6000;

I came across the same issue with MariaDB 10.3.24. Seems like the Warning can occur for all of the above reasons and then some. In my case it was due to a record in one of the database tables which had an empty dictionary value for one of the fields.

+----+--------+ | id | config | +----+--------+ | 3 | {} | +----+--------+

As a test I changed the '{}' to '()' and that stopped the message. Just in case it helps someone.


This my.ini line solved my problem:


Reference this link

  • 22
    I don't think you have solved the underlying problem but have simply stopped it being logged. – user19292 Jan 8 '16 at 12:22
  • 1
    I was having the same message reported as a "Note". Using log_error_verbosity=2 actually solves the "problem" (but a "Warning" should be addressed, not ignored) – xtian Oct 5 '16 at 20:44
  • This appeared to have solved a problem we were seeing with connections on one of our customer's servers, but we still are not sure why. Up voting because I think this answer has merit, even if it doesn't explain why or how the logging verbosity is related to aborted connections. – Matt Casto Mar 2 at 22:40
  • @MattCasto it solves exactly nothing. It is only suppressing the error in the logs. – maxadamo Mar 26 at 17:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.