MySQL Aborted_connects and Aborted_clients climbing: diagnosis

You notice Aborted_connects or Aborted_clients climbing on a production MySQL instance. Because these are cumulative counters, a steady upward slope means something is actively failing or dropping connections. In a busy system, a rising Aborted_connects rate can trigger host blocking via max_connect_errors, suddenly preventing legitimate clients from connecting. A rising Aborted_clients rate usually shows up as application-side exceptions about closed connections, forcing retries that can cascade into connection exhaustion. The two counters track completely different failure modes: Aborted_connects counts connection attempts that never finished authentication; Aborted_clients counts connections that authenticated but then died unexpectedly. Treating them as the same metric leads to wrong fixes. Restarting the network stack will not fix a credential rotation bug, and increasing max_connections will not fix a client killed by wait_timeout.

The counters are usually quiet. A burst correlates with deployments, credential changes, firewall changes, or new monitoring scripts. Move from “the counter is high” to “the counter is rising at an abnormal rate,” then isolate the client or network path.

What this means

MySQL tracks connection failures with two global status counters. Aborted_connects increments when a client initiates a TCP connection but the handshake or authentication does not complete. Causes include bad passwords, SSL handshake failures, connect_timeout expiration, or a host blocked after max_connect_errors consecutive failures. Aborted_clients increments when a client successfully connects but then disconnects without closing the connection properly. Causes include network drops, client application crashes, wait_timeout or interactive_timeout killing an idle connection the client still expects to use, or a query exceeding max_allowed_packet and causing the server to drop the connection.

Both counters are cumulative since server start. Alert on the rate of change, not the absolute value. A common heuristic is to flag when the rate exceeds three times the one-hour rolling baseline. The server also writes [Note] Aborted connection N to db: '...' user: '...' to the error log when log_error_verbosity is set to 3 or higher, giving per-connection detail that aggregate counters lack. Paging on a static cumulative threshold is a mistake: a server up for a year can show a high total with a perfectly healthy current rate.

flowchart TD
    A[Aborted counters climbing] --> B{Which counter rises?}
    B -->|Aborted_connects| C[Check error log for Access denied]
    B -->|Aborted_clients| D[Check error log for Aborted connection]
    C --> E[Query performance_schema.host_cache]
    D --> F[Check wait_timeout and max_allowed_packet]
    E --> G{Host blocked?} -->|Yes| H[TRUNCATE TABLE performance_schema.host_cache]
    F --> I{Network drops?} -->|Yes| J[Review OS network stats]

Common causes

Quick checks

-- Check current counter values and rates
SHOW GLOBAL STATUS LIKE 'Aborted%';
SHOW GLOBAL STATUS LIKE 'Connection_errors%';

-- Check per-host connection errors and blocked hosts
SELECT IP, HOST, SUM_CONNECT_ERRORS, COUNT_HOST_PROXY_ERRORS,
       FIRST_ERROR_SEEN, LAST_ERROR_SEEN
FROM performance_schema.host_cache
WHERE SUM_CONNECT_ERRORS > 0
ORDER BY SUM_CONNECT_ERRORS DESC;

-- Check server timeout and packet settings
SHOW GLOBAL VARIABLES LIKE 'connect_timeout';
SHOW GLOBAL VARIABLES LIKE 'wait_timeout';
SHOW GLOBAL VARIABLES LIKE 'interactive_timeout';
SHOW GLOBAL VARIABLES LIKE 'max_allowed_packet';

# Check error log for recent aborted connection notes
grep -E "Aborted connection|Access denied" /var/log/mysql/error.log | tail -n 20

-- Check if any host is currently blocked
SELECT IP, HOST, SUM_CONNECT_ERRORS
FROM performance_schema.host_cache
WHERE SUM_CONNECT_ERRORS >= @@global.max_connect_errors;

-- Check current connection load against the limit
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Threads_running';
SHOW GLOBAL STATUS LIKE 'Max_used_connections';
SHOW GLOBAL VARIABLES LIKE 'max_connections';

How to diagnose it

1. Determine which counter is rising. Run SHOW GLOBAL STATUS LIKE 'Aborted%'; twice, 60 seconds apart. If Aborted_connects is increasing, the problem is in the handshake or authentication layer. If Aborted_clients is increasing, the problem is post-authentication disconnection.

2. Read the error log. Look for [Note] Aborted connection lines, which indicate Aborted_clients, or Access denied for user lines, which indicate Aborted_connects. Note the source IP, user, and database.

3. For Aborted_connects, query performance_schema.host_cache. High SUM_CONNECT_ERRORS from a single IP suggests a misconfigured client or an attack. If SUM_CONNECT_ERRORS meets or exceeds max_connect_errors, that host is blocked. In MySQL 8.0.23 and later, FLUSH HOSTS is deprecated; use TRUNCATE TABLE performance_schema.host_cache; to reset error counts and unblock hosts. This requires the DROP privilege.

4. For Aborted_clients, compare wait_timeout and interactive_timeout against the application’s connection pool idle timeout. If MySQL kills idle connections faster than the pool recycles them, the pool will attempt to use dead connections and Aborted_clients will climb. Also check if large queries or bulk loads correlate with spikes. If so, verify that client and server max_allowed_packet values match and are large enough for the payload.

5. Check Connection_errors_* counters. Connection_errors_max_connections indicates you are hitting the connection limit, which can cause aborts as clients retry. Connection_errors_accept may indicate OS-level network issues.

6. Correlate with application deployments or infrastructure changes. A sudden step change after a release often points to a new connection string, a rotated password not deployed everywhere, or a changed load balancer health check.

Metrics and signals to monitor

Fixes

Authentication failures and blocked hosts

If performance_schema.host_cache shows a host blocked by max_connect_errors, reset the cache with TRUNCATE TABLE performance_schema.host_cache;. Then fix the underlying client. Do not simply raise max_connect_errors; that only delays lockout and makes brute-force attacks easier. If the source is a misconfigured health check, add credentials or switch to a TCP-only probe that does not initiate the MySQL handshake. If it is a credential rotation issue, identify the application instance with stale credentials and update it. On MySQL 8.4 or later, FLUSH HOSTS is invalid; the only supported reset is TRUNCATE TABLE performance_schema.host_cache;, which requires the DROP privilege on that table.

Tradeoff: TRUNCATE TABLE performance_schema.host_cache; unblocks all hosts immediately, but it also clears the error history, so you lose the forensic trail. Kill the offending client first if possible.

Client timeouts and connection pool churn

When Aborted_clients rises because wait_timeout is shorter than the connection pool’s idle timeout, align the two values. Either increase wait_timeout (risk: more idle connections consuming memory and leaving less headroom under max_connections) or decrease the pool’s idle timeout (risk: more connection setup overhead and thread cache thrashing). For connection pools that validate connections on checkout, enable a validation query like SELECT 1 so the pool discards stale connections before handing them to the application.

Tradeoff: Lower pool idle timeout reduces aborts but increases thread creation overhead. Ensure thread_cache_size is adequate if you reduce pool idle timeouts across many clients. In extreme cases, consider a connection pooler such as ProxySQL to absorb churn at the middleware layer rather than the server layer.

max_allowed_packet violations

If large queries or bulk loads are dropping, verify server and client max_allowed_packet. The mysql client uses --max_allowed_packet, and application connectors have equivalents. The server default is typically 64MB, but clients often default lower. Raise both to a matching value that accommodates your largest legitimate query. If only one side is raised, the other side will still abort the connection.

Tradeoff: Larger packet size allows bigger queries but increases memory usage per connection. Do not raise it indiscriminately without capping query size in the application. An application that sends 500MB queries should be fixed, not accommodated.

Network instability

If packet captures or infrastructure monitoring show retransmits, drops, or duplex mismatches, fix the network path. For Linux, check Ethernet duplex settings; a full/half duplex mismatch produces burst-pause patterns that manifest as intermittent MySQL disconnects. This is a documented edge case in the MySQL manual. If the instability is transient, you can mitigate by increasing net_read_timeout and net_write_timeout, but this only masks the problem.

Tradeoff: Network fixes are outside MySQL but are the only durable solution. Temporary timeout increases reduce aborts at the cost of longer hangs for legitimate queries when the network is degraded.

Prevention

Monitor the rate of both counters, not cumulative absolute values. Alert on a 3x deviation from a one-hour rolling baseline. Monitor performance_schema.host_cache to detect a host approaching max_connect_errors before it is blocked. Align application connection pool idle timeouts with MySQL wait_timeout; a mismatch of even a few seconds can produce a steady stream of aborted clients. Audit health checks and monitoring scripts to ensure they either authenticate correctly or use a TCP-only probe that does not increment Aborted_connects. After credential rotation, watch Aborted_connects for 15 minutes to catch missed instances. If you run MySQL Router, note that versions prior to 9.2 may generate significant connection churn due to frequent metadata cache reconnections. Upgrading to Router 9.2 or later defaults to persistent connections and will reduce baseline noise. Finally, ensure your error log is actively collected and rotated; aborted connection notes are often the fastest way to identify the user and host responsible for a spike.

How Netdata helps

• Netdata surfaces Aborted_connects and Aborted_clients as time-series rates, so you see spikes without manual sampling.
• The MySQL collector exposes Connection_errors_max_connections and other Connection_errors_* counters alongside the aborted counters, letting you correlate handshake failures with specific error conditions.
• Per-second resolution lets you correlate a counter spike with an application deployment or credential rotation event.
• Alerts can trigger on rate-of-change thresholds, such as 3x baseline, rather than static cumulative values, reducing false positives after server restarts.

Related guides

• How MySQL actually works in production: a mental model for operators: /guides/mysql/how-mysql-works-in-production/
• MySQL monitoring checklist: the signals every production instance needs: /guides/mysql/mysql-monitoring-checklist/
• MySQL monitoring maturity model: from survival to expert: /guides/mysql/mysql-monitoring-maturity-model/
• MySQL ERROR 1040 (HY000): Too many connections - causes and fixes: /guides/mysql/mysql-too-many-connections/