Scheduled auto scaling
For workloads with predictable, cyclical patterns or anticipated traffic spikes, use the scheduled auto scaling feature of Database Autonomy Service (DAS). This feature lets you automatically scale up your instance specifications for a defined period to handle the increased database load. After the scaling period ends, the system automatically restores the instance to its original specifications. This helps you meet business demands while controlling costs.
Prerequisites
The database instance must meet the following requirements:
The instance must be one of the following types:
An ApsaraDB RDS for MySQL High-availability Series instance of the general-purpose specification type that uses cloud disks, formerly known as x86 Standard Edition.
NoteScheduled auto scaling is not supported for ApsaraDB RDS for MySQL read-only instances.
A PolarDB for MySQL Cluster Edition instance of the dedicated or general-purpose specification series.
A cloud-native (formerly cloud disk-based) Redis Community Edition or performance-enhanced Enterprise Edition instance that uses the standard architecture.
A DAS service-linked role has been created.
Your account has a sufficient balance to cover the costs of scaling up.
Usage notes
You can only use preset policies to perform scheduled scale-ups on database instances.
All time-related settings are based on the UTC+8 time zone. If your database instance is in a different time zone, you must manually convert the time.
You can apply only one scaling policy of the same mode to each instance.
Scheduled auto scaling does not support automatic retries; if a scaling task fails, the system will not try again.
If you modify the Duration or Scale-back Time after a scale-up event, the system restores the instance to its original specifications based on the latest configuration.
If you specify a Duration or a Scale-back Time, the instance might not be restored to its pre-scaling specifications in the following situations:
Other instance configuration changes, such as manual adjustments or events triggered by dynamic scaling, occurred during the period. If the current instance specifications do not match the target specifications defined in the scaling policy, the system does not perform the scale-back operation.
To ensure business stability and security, the system performs a scale-back only when relevant metrics meet the conditions for a downgrade. For example, an instance is scaled up from 1 GB to 4 GB of memory. Before scaling back, the system checks the current memory usage. If the usage is 1 GB, scaling back to the original 1 GB specification would result in 100% memory utilization. In this case, the system does not perform the scale-back.
The instance is in a state that prohibits configuration changes, such as when its specifications are being changed or it is being migrated. In this case, the system cannot perform the scale-back operation.
Use cases
DAS can scale up an instance once or on a recurring basis, such as daily, weekly, or monthly. For example, a business experiences a peak period from 2:00 on the 1st to 2:00 on the 3rd of every month. You can use the scheduled auto scaling feature to automatically scale up the instance to a higher specification at 2:00 on the 1st and then automatically restore it to the original specification after 2:00 on the 3rd.
Billing
Changing an instance's configuration through scheduled auto scaling incurs fees. For more information, see the following topics:
ApsaraDB RDS for MySQL: See Change instance configuration.
PolarDB for MySQL: See Configuration change fees.
Redis: See Change instance configuration.
Create a scheduled auto scaling policy
Log on to the DAS console.
Create a scheduled auto scaling policy.
Create a policy from the Management and Settings page.
In the left-side navigation pane, click Resource Management > Auto Scaling Settings.
In the Auto Scaling Policies section, click Add Policy. In the Add Policy panel, configure the policy parameters.
Table 1. Parameters
Parameter
Description
Policy Name
The name of the policy.
Mode
Select Scheduled Auto Scaling.
Engine Type
The type of the database engine.
Specifications
The specifications of the selected database engine.
Operation
For ApsaraDB RDS for MySQL and Redis, only Adjust Instance Specifications is supported.
For PolarDB for MySQL, both Adjust Instance Specifications and Increase Number of Read-only Nodes are supported.
Valid From
The Valid From includes a Start date and an End date.
Start date: Required. The value must be on or after the current date.
End date: Optional.
If Recurrence is set to N/A (Execute Only Once), the End date setting does not affect the policy's end time.
If Recurrence is set to Daily, Weekly, or Monthly, the policy runs periodically and indefinitely if you do not set an End date. If you set an End date, the policy is constrained by that End date.
Recurrence
Valid values:
N/A (Execute Only Once)
Scaling Start Time: Required.
Duration: Optional. Enter a positive integer. Unit: hours.
If you do not set a Duration, the system does not restore the instance to its pre-scaling specifications after the policy runs.
If you set a Duration, the system restores the instance to its pre-scaling specifications after the duration ends.
Daily:
Scaling Start Time: Required.
Scale-back Time: Required.
If Scaling Start Time < Scale-back Time, the scaling period starts and ends on the same day.
If Scaling Start Time > Scale-back Time, the scaling period crosses midnight. The Scaling Start Time is on the current day, and the Scale-back Time is on the next day.
NoteThe interval between the Scaling Start Time and the Scale-back Time must be at least one hour.
The Scaling Start Time must be at least one hour after the Scale-back Time of the previous cycle.
If an End date is set and the End date falls between the Scaling Start Time and Scale-back Time of a given cycle, that cycle is not executed.
Weekly
Scaling Start Time: Required.
Scale-back Time: Required.
If Scaling Start Time < Scale-back Time, the scaling period starts and ends in the same week.
If Scaling Start Time > Scale-back Time, the scaling period crosses into the next week. The Scaling Start Time is in the current week, and the Scale-back Time is in the following week.
NoteThe interval between the Scaling Start Time and the Scale-back Time must be at least one hour.
The Scaling Start Time must be at least one hour after the Scale-back Time of the previous cycle.
If an End date is set and the End date falls between the Scaling Start Time and Scale-back Time of a given cycle, that cycle is not executed.
Monthly
Scaling Start Time: Required.
Scale-back Time: Required.
If Scaling Start Time < Scale-back Time, the scaling period starts and ends in the same month.
If Scaling Start Time > Scale-back Time, the scaling period crosses into the next month. The Scaling Start Time is in the current month, and the Scale-back Time is in the following month.
NoteThe interval between the Scaling Start Time and the Scale-back Time must be at least one hour.
The Scaling Start Time must be at least one hour after the Scale-back Time of the previous cycle.
If an End date is set and the End date falls between the Scaling Start Time and Scale-back Time of a given cycle, that cycle is not executed.
In the Auto Scaling Policies section, find the new policy and click Apply in the Actions column.
In the Apply Policiespanel, select the database instances to which you want to apply this policy, and then click the
icon.Click OK to apply the policy to the selected database instances.
Add a scheduled auto scaling policy on the Settings page of the Autonomy Service Settings for the instance.
In the left-side navigation pane, click Intelligent O&M Center > Instance Monitoring.
Find the target instance and click the instance ID to go to the instance details page.
In the upper-right corner, click Autonomy Service Settings.
On the tab. Then, click Add Policy and configure the parameters as described in Parameters to create a scheduled auto scaling policy.
In the Recommended Policies section, find the policy you want to add, and click Apply in the Actions column to add the policy to the instance.
NoteTo modify a policy, click Modify in the Actions column. Modify the settings on the Update Policy tab.
To cancel a policy, find it in the Applied Policies section and click Cancel Policy in the Actions column.
Click OK.
Configure an Alert Template to subscribe to notifications and stay informed about the status of the scheduled auto scaling policy for your database instance.
The system recommends an alert template and adds alert rules for the corresponding autonomy event. You can proceed with the recommended configuration.
NoteIf you have already configured an alert template for the instance, follow the prompts to add the alert rules for the autonomy event to the existing template.
To configure an alert template and alert rules yourself, see Configure an alert template and Configure alert rules.
Select an Alert Contact Group to receive notifications.
Click Add Contact to add a new alert contact.
Click Create Contact Group to create a new alert contact group.
To modify or delete a contact, click Modify or Remove next to the target contact.
For detailed instructions, see Manage alert contacts.
Click Submit Configuration and confirm the alert settings in the dialog box that appears.
View the results of scheduled auto scaling
In the left-side navigation pane, click Intelligent O&M Center > Instance Monitoring.
Find the target instance and click the instance ID to go to the instance details page.
In the left-side navigation pane, click Autonomy Center.
On the Autonomy Center page, view the Auto Scaling Events that occurred within the selected time range.
Click Details for an Auto Scaling Events to view detailed information.
The event notification is recorded with an alert level of Notice and a duration of less than one minute.
FAQ
Q: What do I do if an instance cannot be scaled up because it has reached the specification limit for its series?
A: Purchase an instance of a higher specification series. For example, a dedicated ApsaraDB RDS for MySQL High-availability Edition instance supports up to 104 vCPUs and 768 GB of memory. Then, migrate the data from the original instance to the new one. For more information about database instance specifications and migration solutions, see the following topics:
ApsaraDB RDS for MySQL: ApsaraDB RDS for MySQL instance types and Migrate data between ApsaraDB RDS for MySQL instances.
PolarDB for MySQL: PolarDB for MySQL specifications and Migration between PolarDB for MySQL clusters.
Tair (Redis OSS-compatible): Tair (Redis OSS-compatible) instance specifications and Migrate data between Tair (Redis OSS-compatible) instances.
Related documentation
As your business grows, you may need to change the specifications of your instances. For more information, see the following topics:
ApsaraDB RDS for MySQL: Change instance configuration.
PolarDB for MySQL: Manual scaling.
Redis: Change instance configuration.