This topic describes the principles and usage of the overload protection feature.
Background
In high-concurrency scenarios such as promotional events, the CPU resources of the primary node are prone to overload. To address this issue, database scale-up (upgrade) is usually required. However, transient interruptions or performance drops to zero may occur during the specification change, in which case all requests may be routed to the primary node, causing CPU overload on the primary node and further affecting service continuity and stability. To mitigate this situation, PolarDB for MySQL introduces the overload protection feature at the database proxy layer. This feature protects the primary node by limiting the number of concurrent requests when all read-only nodes are abnormal, ensuring that its overall service availability is not affected.
Limits
-
This feature requires PolarProxy version 2.8.1 or later, and supports PolarDB for MySQL 5.6, 5.7, and 8.0.
-
This feature currently supports only read/write endpoints.
-
Overload protection is triggered only when all read-only nodes are abnormal (crashed or the replication with the primary database is interrupted). Other scenarios are not supported for now.
Usage notes
In the Cluster Endpoint section of the Overview page, click Configure to open the Modify Endpoint Settings page, where you can enable Overload Protection.
Based on the leaky bucket algorithm, when PolarProxy detects that all read-only nodes in the cluster are abnormal, it proactively limits concurrent requests to the cluster to protect the primary database. The limit is lifted when the read-only nodes recover or after the time limit expires (60 seconds by default).
For the throttling limit, PolarDB for MySQL clusters select an appropriate range based on historical data. While the cluster is serving normally, PolarProxy records sampled concurrent request counts of the primary node over the last 24 hours.
When overload protection is triggered, PolarProxy uses the median of the historical data as the upper limit to throttle active connections.
Example
During a test, replication on all read-only nodes is interrupted, triggering overload protection. Traffic can still flow in during this period but does not spike further.
After the read-only nodes recover, overload protection ends and traffic is forwarded normally.
