Change SelectDB cluster configuration-ApsaraDB for SelectDB(SelectDB)-阿里云帮助中心

Cluster scaling

Scaling type	Use cases	Cluster impact
time-sharing auto scaling	The workload has predictable peak and off-peak periods.	When you scale down, the cache size decreases proportionally with the computing resources. Cached data exceeding the new cache size is evicted, which can cause response time jitters for some queries.
manual scaling	The current cluster configuration cannot meet your business requirements.	When you scale down the cache size, cached data that exceeds the target cache size is evicted. This can cause response time jitters for some queries.

Prerequisites

The instance is in the Running state.
The target cluster is in the Running state.
Your Alibaba Cloud account has no unpaid orders.

Usage notes

Overdue payments or an insufficient balance in your Alibaba Cloud account will prevent time-sharing auto scaling rules from running and cause manual scaling attempts to fail.
Scaling operations may briefly interrupt read and write operations. We recommend scaling during off-peak hours.
For time-sharing auto scaling, note the following:
- Only pay-as-you-go clusters support time-sharing auto scaling.
- A time-sharing auto scaling rule is executed only when both the instance and the cluster are in the Running state. If either is in a non-Running state (for example, Paused, Restarting, or Upgrading), the system retries the operation. If the non-Running state persists for more than 30 minutes, the system skips the rule's execution.

Billing

Important

The fees described in this topic are for reference only. For actual costs, refer to your bill.

Each instance can contain one or more Backend (BE) clusters. A pay-as-you-go instance contains only pay-as-you-go clusters, while a subscription instance can contain both subscription and pay-as-you-go clusters. Therefore, billing for scaling a cluster in a subscription instance differs from scaling a cluster in a pay-as-you-go instance.

Subscription instance

Change type	Cluster billing method	Billing details
Scale up the cluster	subscription	Fee to scale up = (Price per day after scale-up - Price per day before scale-up) × Remaining days until instance expiration. For pricing details, see Billable items and pricing. Note The number of remaining days is not an integer and is precise to 12 decimal places. For example, a remaining duration of 31 days and 10 hours is calculated as 31.416666666667 days.
Scale up the cluster	pay-as-you-go	After scaling up a pay-as-you-go cluster, you are charged hourly based on the new configuration. For the hour in which the scaling occurs, you are billed by the minute for both the old and new configurations. The total fee is charged at the end of that hour. For pricing details, see Billable items and pricing.
Scale down the cluster	subscription	After scaling down a subscription cluster, Alibaba Cloud refunds the amount for the remaining subscription duration to your original payment method. For more information about the refund amount, see Unsubscription rules.
Scale down the cluster	pay-as-you-go	After scaling down a pay-as-you-go cluster, you are charged hourly based on the new configuration. For the hour in which the scaling occurs, you are billed by the minute for both the old and new configurations. The total fee is charged at the end of that hour. For pricing details, see Billable items and pricing.

Pay-as-you-go instance

A pay-as-you-go instance is billed on a post-paid basis. After scaling a cluster in a pay-as-you-go instance, the billing method remains unchanged, and you are still charged hourly. For the hour in which the scaling occurs, you are billed by the minute for both the old and new configurations. The total fee is charged at the end of that hour. For pricing details, see Billable items and pricing.

Limitations

Scaling computing resources
- When you adjust computing resources, the cache size is automatically scaled proportionally based on the cluster's current compute-to-cache ratio. For example, for a cluster with 8 CPU cores and 200 GB of cache size, scaling up to 16 CPU cores automatically adjusts the cache size to 400 GB. Scaling down to 4 CPU cores adjusts the cache size to 100 GB.
- You cannot scale computing resources independently while keeping the cache size unchanged.
Scaling cache size
- Scale up: You can scale up the cache size independently or proportionally when scaling up computing resources.
- Scale down: You cannot scale down the cache size independently. To reduce the cache size, you must scale down the computing resources proportionally at the same time.

Note

If you want to scale down only computing resources or only cache size, create a new cluster with the target specifications and then delete the old cluster.

Procedure

Note

Each scaling operation takes about 10 minutes. You can refresh the page to check the cluster status. The operation is complete when the status changes from Changing Specifications to Running.

Time-sharing auto scaling

Log on to the ApsaraDB for SelectDB console.
In the upper-left corner of the page, select the region where your instance is located.
On the Instances page, click the target Instance ID to go to the Instance Details page.
In the left-side navigation pane of the Instance Details page, click Cluster Management.
On the Cluster Management page, find the target cluster and click Scale in the Actions column.
In the Scale panel, click the Time-sharing Auto Scaling tab.

Configure the following settings:

Important

Before you create or modify a Time-sharing Auto Scaling rule, you must understand the following limitations:

The execution time of a new rule cannot overlap with existing rules.
The interval between adjacent rules must be at least one hour. You can create a maximum of 23 rules.
Adjacent rules cannot have the same target computing resources. The last rule and the first rule in the list are also considered adjacent.

Enable or disable the time-sharing auto scaling policy.

In the upper-left corner of the panel, click the Time-sharing Auto Scaling switch.

Note
You must have at least two rules to enable the time-sharing auto scaling policy.

Enabled: The system executes existing rules at their scheduled times. When this policy is enabled, you cannot perform manual scaling.

Disabled: Existing rules are not executed but are not deleted.
Create a time-sharing auto scaling rule.

Important
The system will not execute rules while the time-sharing auto scaling policy is disabled.

Click Create in the upper-right corner of the panel, configure Execution Time and Required Computing Resources, and click Save.

If you have not added any rules, you can also click Create Rule at the bottom of the panel to configure parameters.
Modify a time-sharing auto scaling rule.

In the Actions column of the target rule, click the icon, modify Execution Time and Required Computing Resources, and click Save.
View time-sharing auto scaling rules.

The scaling panel displays the list of time-sharing auto scaling rules by default. If you are on the Manual Scaling tab, click the Time-sharing Auto Scaling tab to switch views.
Delete a time-sharing auto scaling rule.

In the Actions column of the target rule, click the icon. Carefully read the content in the Are you sure that you want to delete the rule? dialog box and click OK.

After deletion, if the number of rules is less than two, the system automatically disables the time-sharing auto scaling policy, and you cannot re-enable it.
Note
1. You cannot delete a rule if its two adjacent rules have the same target computing resources.
2. The last rule and the first rule in the list are considered adjacent.

Parameter	Description
Rule	A temporary ID assigned to the rule. Rules are numbered based on their execution time. If you add or modify a rule, the system automatically re-sorts the entire rule list.
Execution Cycle	The execution frequency for the rule. This is set to Daily and cannot be changed.
Execution Time	The time of day the rule is scheduled to run.
Required Computing Resources	The target computing resources for the cluster, including CPU and memory. Number of CPU cores: `[4, 1024]` Memory: By default, the memory size is four times the number of CPU cores, in GB. Important 1 CCU = 1 CPU core and 4 GB of memory. To request a higher quota, contact Alibaba Cloud technical support.

Manual scaling

Note

You cannot manually scale a cluster while time-sharing auto scaling is enabled. To perform a manual scaling operation, you must first disable the policy and then re-enable it afterward.

Log on to the ApsaraDB for SelectDB console.
In the upper-left corner of the page, select the region where your instance is located.
On the Instances page, click the target Instance ID to go to the Instance Details page.
In the left-side navigation pane of the Instance Details page, click Cluster Management.
On the Cluster Management page, find the target cluster and click Scale in the Actions column.
In the Scale panel, click the Manual Scaling tab.

Configure the target specifications.

Parameter	Description
Required Computing Resources	The computing resources for the cluster, including CPU and memory. Number of CPU cores: `[4, 1024]` Memory: By default, the memory size is four times the number of CPU cores, in GB. Important 1 CCU = 1 CPU core and 4 GB of memory. To request a higher quota, contact Alibaba Cloud technical support.
Required Cache Size (GB)	The cache size for the cluster. Valid values: Minimum value: For target computing resources with 4, 8, 16, or 32 CPU cores, the minimum cache size is 100 GB. For target computing resources with 64 or more CPU cores, the minimum cache size is `100 GB × (Number of selected CPU cores / 32)`. Maximum value: `500 × Number of target CPU cores` Unit: GB
Terms of Service	Read and select the Terms of Service.

Click OK.

Related APIs

Create a time-sharing auto scaling rule

Modify a time-sharing auto scaling rule

Query time-sharing auto scaling rules

Delete a time-sharing auto scaling rule

Enable or disable the time-sharing auto scaling policy

Scale a cluster