max_connect_errors is on a per-host basis, so I doubt that it checks a status variable such as
This variable probably does not apply if you are testing using 'localhost' (which does not use TCP), for what happens if you lock localhost out? No one could connect (assuming a single root user and not being able to log in root remotely)!
So I felt like digging into the source on this one. In the file 'sql/hostname.cc' is a function
ip_to_hostname. This function has the following comments (emphasis mine):
Resolve IP-address to host name.
This function does the following things:
- resolves IP-address;
- employs Forward Confirmed Reverse DNS technique to validate IP-address;
- returns host name if IP-address is validated;
- set value to out-variable connect_errors -- this variable represents the
number of connection errors from the specified IP-address.
NOTE: connect_errors are counted (are supported) only for the clients
where IP-address can be resolved and FCrDNS check is passed.
There is also this comment with regards to localhost (or loopback ip like 127.0.0.1):
*connect_errors= 0; /* Do not count connect errors from localhost. */
Furthermore, the only time connect_errors is incremented is in the function 'inc_host_errors' of the same sql/hostname.cc file. This is only called from the sql/sql_acl.cc file. It looks like these are some of the situations:
1) There is an error with the packets (packet lengths don't match). This is also probably why the documentation says:
If you get the Host 'host_name' is blocked error message for a given host, you should first verify that there is nothing wrong with TCP/IP connections from that host. If you are having network problems, it does you no good to increase the value of the max_connect_errors variable.
2) Invalid native password (function is
3) Invalid old-style password (function is
I might have missed a few things, but ultimately,
max_connect_errors has nothing to do with aborted connections, but rather networking issues or invalid passwords.
For completion sake, I will mention I was looking at the Percona 5.5.15-rel21 source code.
So, what does
Aborted_connects have to do with it? Well, according to this documentation, it gets incremented anytime:
A client does not have privileges to connect to a database.
A client uses an incorrect password.
A connection packet does not contain the right information.
It takes more than connect_timeout seconds to get a connect packet.
Aborted_connects is just an indicator for a DBA to know there might be a problem (eg: if it increases dramatically over a period of time, someone might be attempting to hack into the server, but you should be protected by
max_connect_errors in this case).
If yours increases steadily from the healthchecks, you can still use it if it spikes abnormally.