If the following error occurs, it means that
mysqld has received many connection
requests from the given host that were interrupted in the
middle:
Host 'host_name' is blocked because of many connection errors.
Unblock with 'mysqladmin flush-hosts'
The value of the
max_connect_errors system
variable determines how many successive interrupted connection
requests are permitted. (See
Section 5.1.4, “Server System Variables”.) After
max_connect_errors failed
requests without a successful connection,
mysqld assumes that something is wrong (for
example, that someone is trying to break in), and blocks the
host from further connections until you issue a
FLUSH HOSTS
statement or execute a mysqladmin
flush-hosts command.
By default, mysqld blocks a host after 10
connection errors. You can adjust the value by setting
max_connect_errors at server
startup:
shell> mysqld_safe --max_connect_errors=10000 &
The value can also be set at runtime:
mysql> SET GLOBAL max_connect_errors=10000;
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.
I am running 3.23.49-nt on Win2K advanced server w/ 2GB of RAM. When I set max_connections parameter to 1000, connection time takes too much. Keep it as low as you can
Posted by Roel van der Made on August 19 2004 4:42am
The setting of 10000 on our Debian GNU/Linux environment (4 MySQL 4.0.20 servers with 4GB ram and dual Xeon 2.8 procs) worked out very well. So the previous poster's comment does certainly not affect all platforms. I also think the default setting of 10 is a bit low, 1000 would be more likely..
We ran into this problem because we use "nagios" as an availabilty monitor for our MySQL server. We were unaware of the custom nagios plugin to check mysql so we were doing a simple TCP/IP connection to the MySQL server to verify that it would receive the connection. This would eventually trigger this max-errors problem for us. However, it would only trigger it when there was no other activity on the MySQL server, making me believe that this max-errors number applies to consecutive bad connections, not bad connections intermingled with good ones.
We were not seeing any errors in the mysqld.log that led us to determine that our nagios check was the cause; luckily we realized it eventually.
Posted by Gunnar Gunnarsson on September 29 2004 6:28pm
I got a host to be connection blocked by server, however, those errors were not displayed in mysql error log, even log_warning is ON, wonder that should not be normal.
Posted by Christian Hammers on November 23 2004 2:38pm
Regarding the error log, mysqld prints errors to stderr which gets into the mysql.err logfile. If you rotate that away all further messages will never show up as flush-logs does not reopen stderr! (This does not apply to Debian Sarge and newer versions as they are patched to log error messages to syslog via a pipe to "logger")
Posted by Joshua Franklin on December 1 2006 8:52pm
© 2013, Oracle Corporation and/or its affiliates
User Comments
I am running 3.23.49-nt on Win2K advanced server
w/ 2GB of RAM. When I set max_connections
parameter to 1000, connection time takes too
much. Keep it as low as you can
The setting of 10000 on our Debian GNU/Linux environment (4 MySQL 4.0.20 servers with 4GB ram and dual Xeon 2.8 procs) worked out very well. So the previous poster's comment does certainly not affect all platforms.
I also think the default setting of 10 is a bit low, 1000 would be more likely..
This section of the manual is regarding max_connect_errors, and NOT max_connections - the previous two 'tips' are in the wrong section.
We ran into this problem because we use "nagios" as an availabilty monitor for our MySQL server. We were unaware of the custom nagios plugin to check mysql so we were doing a simple TCP/IP connection to the MySQL server to verify that it would receive the connection. This would eventually trigger this max-errors problem for us. However, it would only trigger it when there was no other activity on the MySQL server, making me believe that this max-errors number applies to consecutive bad connections, not bad connections intermingled with good ones.
We were not seeing any errors in the mysqld.log that led us to determine that our nagios check was the cause; luckily we realized it eventually.
A very useful link in relation to blocked hosts:
http://dev.mysql.com/doc/mysql/en/Communication_errors.html
I got a host to be connection blocked by server, however, those errors were not displayed in mysql error log, even log_warning is ON, wonder that should not be normal.
Regarding the error log, mysqld prints errors to stderr which gets into
the mysql.err logfile. If you rotate that away all further messages will never show up as flush-logs does not reopen stderr!
(This does not apply to Debian Sarge and newer versions as they are patched to log error messages to syslog via a pipe to "logger")
We had the same problem with Nagios so I opened a bug:
http://bugs.mysql.com/bug.php?id=24761
Add your own comment.