List:Internals« Previous MessageNext Message »
From:Fabian Thylmann Date:March 20 2006 12:02am
Subject:max_connect_errors
View as plain text  
Hi,

I hope this is the right list to make this suggestion in or discuss this.

I have had multiple problems with max_connect_errors, especially at the 
default setting of 10. Although I fully agree such a setting must be 
there, and I actually also agree that the setting of 10 is ok if 
implement correctly, I totally disagree to the way it was implemented in 
mySQL.

As far as I see it, the main reason max_connect_errors exists is to help 
against DOS attacks for example which could totally hinder mySQL to do 
its job. A malicious attacker could continuously connect to mysql and 
drop again, causing mysql to work up its connections and get swamped 
with connect errors which are very low work for the attacker but 
annoying to mySQL.
Also, an attacker could go and try brute forcing a password to get into 
mySQL and max_connect_errors would simply lock them out quickly.

This all makes sense. As far as I understand any of the things listed 
here will cause the counter to be increased:

http://dev.mysql.com/doc/refman/5.0/en/communication-errors.html

That might be wrong and it only is effected by the errors listed there 
that happen during the connection phase, so that limits them somewhat.

The problem remains though. And to finally get to the problem, here it is:
Imagine a server setup where the mySQL server has a somewhat bad 
connection to the servers that connect to it. This might be because they 
are far apart, or traffic on the network is high or similar things. Now 
of course this would cause connect errors to happen now and then.
The problem now is that mySQL does not care, at least I see no evidence 
for it doing so, how far apart connect errors actually occur. So, 
theoretically, they could be an error, a fully legitimate one, every 2 
days, and after 20 days of uptime the connection to the database is 
totally broken and has to be manually fixed via a flush-hosts command. 
This is obviously not the goal of the max_connect_errors setting.
So, what I suggest is to add another setting to mySQL, lets call it 
something like: connect_error_deduction. This setting could work in 2 ways:
1) Simply allow someone to set how much the connect_errors counter 
should be deducted in a specific timeframe, for example every 10 minutes.
2) Or, what might be a better solution, a setting for how much the 
connect_errors counter should be deducted for every 100 (for example) 
GOOD connections that occur. For example, setting this to 10, would 
cause the counter to be deducted by 1 every 10 successfully closed 
connections that did not cause any errors.

This would keep the connect_errors counter clean and would not cause 
FULL connection failures because of bad connections between servers and 
them being totally locked out.

Again, I hope this was the right place to post this, would like to hear 
what everyone thinks.

Fabian
Thread
max_connect_errorsFabian Thylmann20 Mar
  • Re: max_connect_errorsElliot Murphy23 Mar
    • Re: max_connect_errorsmysql23 Mar
    • Re: max_connect_errorsFabian Thylmann23 Mar
      • Re: max_connect_errorsElliot Murphy24 Mar