Bug#99917: Limit connections on the administrative interface

[vidyadharchelluru]

What does this change do?

The administrative connection interface (admin_address/admin_port) accepts an unlimited number of connections. Any account holding SERVICE_CONNECTION_ADMIN can therefore exhaust server threads through the administrative interface, and max_connections offers no protection there. Bug#99917 requests an option to cap number of connections on admin interface.

This change adds:

• admin_max_connections: GLOBAL, dynamic ulong, range 0..100000, default 0. Caps the number of concurrent connections accepted on the administrative interface. 0 preserves the previous unlimited behaviour, so the default is fully backward compatible. max_connections and admin_max_connections are enforced independently: the former continues to govern only ordinary connections, the latter only administrative ones.

• Admin_connections status variable: number of currently open administrative connections. Ordinary connections never touch it.

• Admin_connection_errors_max_connections status variable: number of administrative connections refused because admin_max_connections was reached. These rejections deliberately do not increment Connection_errors_max_connections, which keeps counting only ordinary connections refused by max_connections. Threads_connected keeps counting all connections including administrative ones (unchanged).

Implementation: both counters are static members of Connection_handler_manager protected by the existing LOCK_connection_count mutex, so no new synchronization primitive or PSI key is needed. check_and_incr_conn_count() rejects an administrative connection with ER_CON_COUNT_ERROR when the cap is reached; lowering the cap below the number of open administrative connections affects new
connections only. dec_connection_count() gains an optional is_admin_connection argument (default false) so the counter stays
balanced on every disconnect path of the per-thread and one-thread handlers. Internal sessions (srv_session_service passes
ignore_max_connection_limit as the first argument) are excluded on both the check and increment side via the internal_session argument. The exported dec_connection_count() hook in thread_pool_priv.h keeps the default; a thread pool implementation serving the administrative interface would need to pass the flag through.

Why is it needed?

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."

This change implements the max connections limit

How was it tested?

• Added/updated MTR tests under mysql-test/
• scripts/ci/mtr.sh passes locally
• Ran the relevant full suite (name it): ______

Tests: main.admin_max_connections (functional coverage incl. status variable separation), sys_vars.admin_max_connections_basic, plus
bookkeeping updates to all_persisted_variables (450 -> 451) and mysqld--help-notwin.

Contributor checklist

• Code is formatted (scripts/ci/format.sh)
• Commits are focused with descriptive messages

AI assistance

• I did not use AI assistance for this contribution
• I used AI assistance for this contribution

If AI assistance was used, describe the tool(s) and extent of use:

AI Assistance:
We have used Claude Optus 4.8 for implementation of status variables related code.
Validation of complete patch to be in mysql required format
Added comments automatically in required places using AI
For automated code review and test case generation (tested far many cases than exist in MTR with real workload to ensure it has no regression)

Human Validation:
Complete Idea has been developed manually
The complete code related to addition of parameter implemented manually.
The code has been reviewed manually before submission.

Areas touched

Admin interface connection handler
mysqld.h/cc and sys_var.cc modified to include new parameter.

[oracle-contributor-agreement]

Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA).
The following contributors of this PR have not signed the OCA:

• PR author: vidyadharchelluru

To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application.

When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated.

If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public.

[vidyadharchelluru]

I confirm the code being submitted is offered under the terms of the OCA signed by Amazon, and that I am authorized to contribute it.

[oracle-contributor-agreement]

Thank you for signing the OCA.