Managing traffic spikes manually — watching CPU metrics and resizing clusters at the right moment — is time-consuming and error-prone. Auto scaling monitors your PolarDB for MySQL 5.6 cluster continuously and adjusts its specifications and read-only node count automatically based on CPU utilization and read/write traffic. When traffic spikes, the cluster scales out or up to maintain performance. During off-peak hours, it scales back to reduce costs.
Auto scaling is supported only for PolarDB for MySQL 5.6. Other versions support the serverless feature, which provides similar elastic scaling. For more information, see Enable the serverless feature for a cluster with defined specifications.
How it works
When CPU utilization crosses the configured threshold during the observation period, the system selects a scaling method based on inbound read and write traffic:
Scale-up: Upgrades cluster specifications in small increments (for example, from 4 cores to 8 cores to 16 cores) until the configured maximum specification is reached.
Scale-out: Adds one or two read-only nodes at a time until the configured maximum node count is reached.
Scaling timeline: From the moment a threshold is crossed until scaling completes, at least 15 minutes pass — 5 minutes (minimum observation period) plus 10 minutes to complete the scaling activity. Do not use auto scaling for workloads with peak durations shorter than 15 minutes.
Scale-in behavior: After scaling out or up, the system continuously evaluates whether to scale back, provided the cluster is not in the quiescent period. The scale-in observation window equals the observation period plus 10 minutes. For example, if the observation period is 30 minutes, scale-in is evaluated over a 40-minute window. If average CPU utilization of automatically scaled nodes stays below 30% for more than 99% of that window, the cluster scales back tier-by-tier to its original specifications.
Quiescent period (cooldown): After a scaling activity completes, the quiescent period begins. During this cooldown, PolarDB continues monitoring resource usage but does not trigger further scaling. If the cooldown ends at the same time as an observation period and CPU utilization still exceeds the threshold, scaling is triggered immediately.
The sequence is: threshold crossed → observation period → scaling executes → quiescent period starts → next observation begins.
Prerequisites
Before you begin, make sure that:
The cluster runs PolarDB for MySQL 5.6
No cluster configuration change tasks are in progress
Limitations
| Limitation | Details |
|---|---|
| Scaling scope | Applies to the entire cluster. You cannot scale an individual node. |
| Disconnection during scale-up | All nodes in the cluster experience a transient disconnection of up to 30 seconds. Configure your applications with automatic reconnection to handle this. Scale-out does not cause disconnections. |
| Read-only node performance | Read-only node performance degrades temporarily during a scaling activity. Read requests may take longer to complete. |
| Data safety | Data stored in the cluster is not affected during scaling. |
| Scale-in dependency | Auto scale-in requires auto scale-out to be enabled. If you disable auto scaling after a cluster has scaled out, the cluster is not automatically scaled back. |
| Minimum peak duration | Auto scaling takes at least 15 minutes to take effect. Do not use it for workloads with very short traffic spikes. |
Billing
Scaling fees are based on your cluster's billing method. For details, see Change the configurations.
| Billing method | How fees are calculated |
|---|---|
| Pay-as-you-go | Charged by the hour at the new configuration's price, effective immediately after the change. |
| Subscription | Payment = (New monthly price / 30 / 24 × Unused hours) − (Original monthly price / 30 / 24 × Unused hours). For example: new configuration at USD 14,400/month, original at USD 7,200/month, 50 days remaining → payment = USD 12,000. |
Enable auto scaling
Log on to the PolarDB console. In the left-side navigation pane, click Clusters. Select a region, then click the cluster ID to open the Basic Information page.
In the Database Nodes section, click Settings in the upper-right corner.
In the dialog box, configure the following parameters, then confirm your changes.
| Parameter | Description |
|---|---|
| Auto Scaling-out | Enables auto scaling. |
| Observation Period | The time window during which CPU utilization is monitored before a scaling action is triggered. The minimum is 5 minutes. Combined with the 10-minute execution time, auto scaling takes at least 15 minutes to take effect after a threshold is crossed. |
| CPU Usage | The CPU utilization threshold that triggers a scale-up. When average CPU utilization of the cluster reaches or exceeds this value during the observation period, the system scales up or out. |
| Maximum Specification | The highest specification the system can scale up to. The cluster is upgraded in small increments until it reaches this limit or CPU utilization drops below the threshold. |
| Maximum Number of Read-only Nodes | The maximum number of read-only nodes the system can add. Nodes are added one or two at a time. To restrict scaling to specification upgrades only (no new nodes), set this to the cluster's current read-only node count. Note Automatically added nodes are associated with the cluster's default endpoint. If you use a custom endpoint, control whether new nodes join it using the Automatically Associate New Nodes parameter. For details, see Configure PolarProxy. |
| Auto Scaling-in | Enables automatic scale-back. When enabled, the cluster scales back tier-by-tier to its original specifications if average CPU utilization of automatically scaled nodes stays below 30% for more than 99% of the scale-in observation window (observation period + 10 minutes). Disable scale-in if you want the cluster to retain its scaled-out capacity after a peak — for example, after a promotional event when traffic may remain elevated, or when you want to avoid the brief disconnection that scale-up causes during scale-back. |
| Quiescent Period | The minimum interval between two consecutive scaling activities (the cooldown period). PolarDB continues monitoring resource usage during this time but does not trigger scaling. See the timeline in How it works for the relationship between the observation period and the quiescent period. |