Why ScaleArc enforces increasing max_connect_errors?
Prior to ScaleArc 3.5, ScaleArc allows users to create a cluster with a database server whose max_connection and max_connect_error variables are set less than 999999. After ScaleArc 3.5 onwards, this became a requirement.
See more at: KB Article
The reason for such alerting to increase the max_connect_error are as follows:
- If Password changed on database server and not updated on Scalearc:
All connection created from scalearc to DB server after this will fail causing the max_connect_error to be reached without having a single successfully connection.
- High Network Latency:
This can cause connections created from scalearc towards the DB server to timeout (10sec timeout). If this happens in a burst without a single successful connection then MySQL server will block us, if max_connect_error limit is reached.
- There are other possible scenarios like:
scalearc opened server connections in burst and crashed instantly without completing even a single successful connection.
All the above reasons can cause the MySQL server to block connections from scalearc, if max_connect_error is reached.
If you are looking for a mechanism to limit exposure to brute-force attempts to access MySQL, max_connect_error won’t help you. If you’re worried about a SYN flood attack, max_connect_error might help you in very specific situations. PERFORMANCE_SCHEMA improvements in MySQL 5.6 expose meaningful information about potential brute-force attacks, but again – only in situations where the host cache is involved. Beyond that, the contents of MySQL Enterprise Audit log or general query log can be mined to identify such attacks.
If you are experiencing issues with ScaleArc or with any of it's features, please contact ScaleArc Support. We are available 24x7 by phone at 855 800 7225 or +1 408 412 7315. For general support inquiries, you can also e-mail us at firstname.lastname@example.org.
2901 Tasman Drive Santa Clara, CA 95054 | Email: email@example.com