PolarDB for MySQL provides the auto scaling feature, which effectively handles traffic peaks and ensures the stability of your cluster. The feature monitors the average CPU utilization of your cluster and, based on the real-time read and write traffic, intelligently selects a scaling method of adding nodes or upgrading specifications. In addition, auto scaling supports automatic scale-in, which allows the cluster to automatically return to its original specifications during off-peak hours.
Currently, only PolarDB MySQL 5.6 clusters support the auto scaling feature. All other editions already support Serverless, which delivers second-level elastic scaling of nodes by using the Serverless feature. For more information, see Enable serverless for fixed-specification clusters.
Prerequisites
PolarDB for MySQL clusters must meet the following requirements:
Database engine must be MySQL 5.6.
No configuration change is in progress.
Considerations
The auto scaling feature takes at least 15 minutes to take effect and is therefore not suitable for short-lived traffic peaks. If you enable auto scaling but do not enable automatic scale-in, the cluster cannot automatically scale back after it scales out during a traffic peak. You also cannot enable automatic scale-in without enabling auto scaling. If both are enabled, the cluster automatically scales out and scales back based on your business requirements.
Auto scaling can upgrade or downgrade the specifications of only the entire cluster. You cannot upgrade or downgrade the specifications of an individual node in the cluster.
During a cluster configuration change, a transient disconnection of about 30 seconds may occur. Make sure that your applications support an automatic reconnection mechanism.
During a cluster configuration change, read-only requests may lag behind read and write requests for a longer period than they do during normal operation.
Upgrading or downgrading the cluster specifications does not affect the existing data in the cluster.
Billing
When the cluster scales out, the system calculates the fees based on the billing method of the cluster and the configuration change. For more information, see Billing of configuration changes.
Billing method | Fees |
Pay-as-you-go | Pay-as-you-go clusters are billed hourly. After you change the configuration, they are billed hourly at the new price. |
Subscription | Payment fee = Total price for the remaining duration of the new configuration (monthly price of the new configuration ÷ 30 ÷ 24 × remaining subscription duration) − total price for the remaining duration of the old configuration (monthly price of the old configuration ÷ 30 ÷ 24 × remaining subscription duration). Example: The new configuration costs USD 14,400 per month, and the old configuration costs USD 7,200 per month. The subscription has 50 days remaining. The fee to pay is (14,400 / 30 / 24 × 50 × 24) - (7,200 / 30 / 24 × 50 × 24) = USD 12,000. |
Procedure
Log in to the PolarDB console，In the navigation pane on the left, click Clusters. Select the Region where the cluster is deployed, and then click the cluster ID to go to the cluster details page。
On the Basic Information page, in the Database Nodes section, click Settings in the upper-right corner.
In the dialog box that appears, configure the following parameters:
Parameter
Description
Auto Scaling-out
The switch that enables auto scaling.
Observation Period
If the average CPU utilization is greater than or equal to the specified value throughout the observation window, then after the observation window ends, PolarDB selects a scaling method of adding nodes or upgrading specifications based on the real-time read and write traffic of the cluster. The minimum observation window is 5 minutes, so the waiting time is at least 15 minutes. For example, if the observation window is 5 minutes and auto scaling takes 10 minutes, you need to wait about 15 minutes to see the effect of auto scaling.
NoteThe scale-in observation window is the observation window plus 10 minutes. For example, if Observation Window is set to 30 minutes, the scale-in observation window is 40 minutes.
CPU Usage
The threshold that triggers auto scaling. When CPU Usage is greater than or equal to the specified value, auto scaling is triggered.
Maximum Specification
The upper specification limit for auto scaling. After auto scaling is triggered, the cluster specifications of PolarDB are upgraded tier by tier, for example, from 4 cores to 8 cores and then to 16 cores, until the upper scaling limit is reached.
Maximum Number of Read-only Nodes
The maximum number of read-only nodes that auto scaling can add. After auto scaling is triggered, the system adds one to two read-only nodes based on actual conditions until the upper limit is reached.
NoteNodes added by auto scaling are associated with the default endpoint of the cluster. For a custom endpoint, you must configure Automatically Associate New Nodes. For more information about how to configure Automatically Associate New Nodes, see Configure the database proxy.
If you want to upgrade specifications only without adding nodes, set the upper limit of read-only nodes to the current number of read-only nodes.
Adding nodes does not cause a transient disconnection, but upgrading specifications does. In addition, a specification upgrade applies to all nodes in the cluster, not only the node that triggered the upgrade.
Auto Scaling-in
The switch that enables automatic scale-in.
NoteAfter automatic scale-in is enabled, if the cluster is not in the cool-down period and the average CPU utilization of the nodes added by auto scaling stays below 30% for more than 99% of the scale-in observation window (observation window + 10 minutes), the system automatically scales back the cluster specifications tier by tier until the original specifications are restored.
If the cluster has scaled out but has not yet scaled back, and you disable the auto scaling feature, the cluster is not automatically scaled back.
Quiescent Period
The minimum interval between two consecutive automatic scale-out or scale-in activities. During the cool-down period, PolarDB continues to monitor the cluster but does not trigger automatic scale-out or scale-in. If the cool-down period and the observation window end at the same time and the CPU utilization within that observation window reaches the adjustment threshold, PolarDB triggers an automatic specification adjustment when the cool-down period and the observation window end.