MySQL "Too Many Connections," Accessing via the Dedicated Admin Port

MySQL 8.0.14 and later support a dedicated administrative connection port (extra_port), specifically designed to let a database administrator connect and investigate even when the regular connection pool is completely exhausted — this is a purpose-built, legitimate administrative feature, distinct from and more flexible than the older, more limited superuser-reserved-connections mechanism.

The Problem

The regular MySQL connection pool is completely exhausted, and every normal connection attempt fails:

ERROR 1040 (HY000): Too many connections

You need to connect specifically to investigate and resolve the underlying cause (identify what's consuming all available connections, terminate problematic sessions), but the standard connection path is itself blocked by the very problem you're trying to diagnose.

Why a Dedicated Admin Port Exists

The older mechanism, superuser_reserved_connections, reserves a small number of slots within the main connection pool exclusively for superuser use — functional, but limited, since it's still part of the same pool and the same listening port, and can itself become contended under certain conditions. MySQL 8.0.14 introduced a genuinely separate, dedicated network port specifically for administrative connections, configured via extra_port, providing a cleaner, more robust separation between regular application traffic and emergency administrative access — connections through this dedicated port don't compete with regular connections for the same pool at all.

The Fix

First, confirm whether your MySQL instance has extra_port configured, since this needs to be set up in advance — it's not available by default without explicit configuration:

SHOW VARIABLES LIKE 'extra_port';

If this is already configured with a specific port number (rather than 0, which means disabled), you can connect through it directly, even while the main port is fully exhausted:

mysql -u root -p -h 127.0.0.1 -P 33062  # the configured extra_port value

If extra_port isn't currently configured, and you have access to modify the server's configuration (and can restart the server, since this specific setting typically requires a restart to take effect), configure it proactively for future situations, rather than only discovering the need for it during an actual live incident:

# my.cnf
[mysqld]
extra_port = 33062
extra_max_connections = 5

extra_max_connections controls how many concurrent connections the dedicated admin port itself can accept — a small number is generally appropriate, since this port is meant for occasional, deliberate administrative access, not regular application traffic of any kind.

Once connected via the admin port during an actual connection-exhaustion incident, investigate what's actually consuming the regular connection pool:

SELECT count(*), user, host, command
FROM information_schema.processlist
GROUP BY user, host, command
ORDER BY count(*) DESC;

Identify and terminate any connections that are clearly problematic — idle, abandoned, or otherwise not doing legitimate active work — freeing up capacity in the regular pool:

KILL <connection_id>;

If you don't have extra_port pre-configured and are in the middle of an active incident without the ability to restart the server to add it, fall back to the older superuser_reserved_connections mechanism instead, connecting as a genuine superuser through the regular port, which still reserves a small number of slots specifically for this purpose even without the newer dedicated-port feature configured:

mysql -u root -p -h localhost

For a longer-term fix addressing the root cause rather than just providing emergency access during incidents, implement proper connection pooling at the application level (as covered in more detail in a related connection-pool-exhaustion topic), which reduces the likelihood of hitting this exhaustion scenario at all under normal operation.

Still Not Working?

If neither the dedicated admin port nor reserved superuser connections are available or configured, and you're facing a genuine production incident with no administrative access path remaining, the most direct remaining option is restarting the MySQL service itself, which forcibly terminates every existing connection and returns the server to a clean, connectable state — this is disruptive to any currently active legitimate connections and should be a last resort, but is preferable to an extended outage with literally no way to investigate or intervene, and reinforces the value of proactively configuring extra_port ahead of time specifically so this kind of last-resort restart isn't your only remaining option during a future incident of the same kind.