[MDEV-8478] Skip max_connect_errors Created: 2015-07-17  Updated: 2016-12-13  Resolved: 2016-12-13

Status: Closed
Project: MariaDB Server
Component/s: Replication
Fix Version/s: N/A

Type: Task Priority: Minor
Reporter: Geoff Montee (Inactive) Assignee: Sergei Golubchik
Resolution: Won't Fix Votes: 1
Labels: None


 Description   

Rather than setting max_connect_errors really high, some users would like to skip host blocking entirely. Can we implement someway to allow unlimited max_connect_errors? If so, how would we implement it?

1.) Set max_connect_errors to 0 for unlimited.

2.) Create a new setting, such as "skip_max_connect_errors".

MySQL has said that they don't want to implement this:

https://bugs.mysql.com/bug.php?id=7695



 Comments   
Comment by Elena Stepanova [ 2015-07-17 ]

Their explanation about 0 being a valid choice sounds reasonable given the current definition of the variable, only it's wrong, because as the bug report says, you cannot set max_connect_errors=0.
On the other hand, if the definition is changed slightly, 0 could just as well mean unlimited.
Currently it's

If more than this many successive connection requests from a host are interrupted without a successful connection, the server blocks that host from further connections.

In this case, 0 indeed should be a valid value meaning after the very first connection error the host gets blocked. Only, the value is not allowed.

But if it were

If this many successive connection requests from a host are interrupted without a successful connection, the server blocks that host from further connections.

then 1 would mean that after the very first connection error the host gets blocked; and then 0 could mean unlimited.

That said, I don't see much problem with setting a really high value, what's wrong with that? We do it for pretty much all variables, e.g cache sizes, log sizes and what not. And if a user does not like big numbers, they can set it to -1, it will be adjusted.

Comment by Geoff Montee (Inactive) [ 2015-07-17 ]

That said, I don't see much problem with setting a really high value, what's wrong with that? We do it for pretty much all variables, e.g cache sizes, log sizes and what not.

I don't personally see anything wrong with that.

In this case, I think disabling the blocking is about peace of mind, rather than anything technical. The costs of having a host blocked would be very high, so the user would prefer to disable host blocking entirely.

And if a user does not like big numbers, they can set it to -1, it will be adjusted.

Should that automatically be cast to 2^64-1? It doesn't seem to work for me. Am I doing something wrong?

MariaDB [(none)]> SET GLOBAL max_connect_errors=-1;
Query OK, 0 rows affected, 1 warning (0.00 sec)
 
MariaDB [(none)]> SHOW WARNINGS;
+---------+------+----------------------------------------------------+
| Level   | Code | Message                                            |
+---------+------+----------------------------------------------------+
| Warning | 1292 | Truncated incorrect max_connect_errors value: '-1' |
+---------+------+----------------------------------------------------+
1 row in set (0.00 sec)
 
MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'max_connect_errors';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| max_connect_errors | 1     |
+--------------------+-------+
1 row in set (0.00 sec)

Comment by Elena Stepanova [ 2015-07-17 ]

I meant on startup.

mysqld <...> --max-connect-errors=-1

2015-07-17 20:12:11 139936639149920 [Warning] option 'max_connect_errors': unsigned value 18446744073709551615 adjusted to 4294967295

MariaDB [test]> select @@max_connect_errors;
+----------------------+
| @@max_connect_errors |
+----------------------+
|           4294967295 |
+----------------------+
1 row in set (0.00 sec)
 
MariaDB [test]> select @@version;
+----------------------+
| @@version            |
+----------------------+
| 10.1.6-MariaDB-debug |
+----------------------+
1 row in set (0.00 sec)

Comment by Geoff Montee (Inactive) [ 2015-07-17 ]

Oh, OK. Thanks for clarifying!

Generated at Thu Feb 08 07:27:27 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.