During high-traffic events such as promotions, when all read-only nodes in a PolarDB for MySQL cluster go down simultaneously—due to crashes or replication failure—all traffic is rerouted to the primary node. During a node upgrade, this causes a sharp spike in concurrent requests that can overwhelm the primary node and result in service interruption. Overload protection prevents this by automatically throttling concurrent requests at the PolarProxy layer until the read-only nodes recover.
How it works
PolarProxy continuously samples the number of concurrent requests on the primary node and keeps a rolling 24-hour history.
When PolarProxy detects that all read-only nodes are faulty, it activates overload protection:
Throttle: PolarProxy caps active connections using the median of the 24-hour historical data as the concurrency limit. This is based on the leaky bucket algorithm.
Continue serving: Requests within the limit are routed to the primary node.
Auto-release: Overload protection is lifted when read-only nodes recover, or after 60 seconds—whichever comes first.
Prerequisites
Before you begin, ensure that you have:
PolarProxy version 2.8.1 or later
A PolarDB for MySQL 5.6, 5.7, or 8.0 cluster
A read/write endpoint (cluster endpoint)
Enable overload protection
On the Overview page, go to the Cluster Endpoint section and click Modify.
On the Configure Node page, enable overload protection.
Limitations
Overload protection applies only to read/write endpoints. It is not supported on read-only endpoints.
The feature triggers only when all read-only nodes are faulty—either due to a node crash or a replication interruption with the primary database. It does not activate in other scenarios.
Example
The following chart shows what happens when replication on all read-only nodes is interrupted during a test. After overload protection activates, the request rate to the primary node stays flat rather than spiking. After the read-only nodes recover, the protection is lifted and traffic resumes normally.
