MySQL Bugs: #99917: Provide option to restrict number of connection on administrative interface

Bug #99917	Provide option to restrict number of connection on administrative interface
Submitted:	17 Jun 2020 15:28	Modified:	25 Aug 7:44
Reporter:	Chelluru Vidyadhar	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: Options	Severity:	S4 (Feature request)
Version:	8.0.19, 8.0.20	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
The new administrative interface enabled using admin_address and admin_port variables helpful in many scenarios for example "Handling too many connections" issue.

However, as of now there is no limit on number of connections that can be established using administrative interface.

"There is no limit on the number of administrative connections."

https://dev.mysql.com/doc/refman/8.0/en/administrative-connection-interface.html#administr...

It would be really helpful, if we can add another option like max_admin_connections to limit number of connections from admin interface.

How to repeat:
None.

Hello Chelluru,

Thank you for the feature request!

regards,
Umesh

Reporter submitted a PR that implements this: https://github.com/mysql/mysql-server/pull/727

My question to Chelluru: Isn't this going around in circles though? If you now set a limit on max admin connections, and you actually reach that limit, what happens next? Is it the case that you use the admin_address all the time, not just as a backup / overflow channel when max_connections was reached?

Agree with Henrik Ingo.

The purpose of admin interface is to provide a predictable recovery path when regular interface is no longer reachable.For this to happen, the access should not be blocked based on number of connections. Applications should not use this interface like regular server-client interface.

Thanks Henrik, Harin. Both are fair questions, and the second deserves a direct answer, so let me take them in order.

> On the circularity concern (if a limit is set and then reached, what happens next?)

The choice is not between a limit and no limit. It is between a limit the operator defines and one the system imposes implicitly.

The admin interface has no configured ceiling today, but it still has a hard one. Threads, stacks, file descriptors, and memory are finite, and the admin port shares them with the ordinary interface. The cap therefore already exists. It simply sits at an unknown value, becomes visible only under failure, and is enforced by thread-creation failure or the OOM killer rather than by a clean refusal.

This is the opposite of what an interface intended for recovery should do. "No limit" reads as an assurance that the operator can always connect. It is not one. If those resources have already been consumed through the admin port, the recovery connection fails as well, and it fails in an uncontrolled manner, at precisely the moment the interface exists to serve.

A configured cap produces a different outcome. When the limit is reached, the additional connection receives an immediate, well-defined error while the server still has resource headroom, and the capacity the operator reserved for the recovery connection remains available. The limit does not reintroduce the lockout. It relocates the refusal to the correct connection (the excess one) and to the correct time (early), while preserving the ordinary interface. It replaces an implicit, undiscoverable limit with an explicit one the operator can reason about and size appropriately.

> On whether admin_address is used continuously

Yes, and this is the point I want to state precisely. In managed deployments the admin port is not idle between incidents. It carries several long-lived operational clients: health checks, monitoring collectors, backup coordination, and failover and orchestration agents, in addition to the DBA executed automations (like recover from max_connections as example). None of this is application traffic, and I agree fully with Harin that applications should never target this interface.

The current design assumes a single operator. In practice there are several automated ones, all legitimately administrative, and each holds SERVICE_CONNECTION_ADMIN. Any of these agents can leak connections following a network interruption or a defect in a reconnect loop. This requires no malice, only an ordinary software defect. Without a ceiling, that leak is bounded only by the host's resources, and it degrades the ordinary interface as it grows.

The request is therefore not about capacity. It is a safety valve, so that a single misbehaving administrative client cannot exhaust the host and disable both interfaces at once.

> The specific request

Retain the default of unlimited connections (admin_max_connections = 0), so that behavior is unchanged for anyone who prefers it today and the recovery guarantee remains intact. Provide experienced operators the option to configure a ceiling on the admin interface, so that those running multiple administrative automations can protect the server against their own automation defects.