You can flexibly scale your Tair (Redis OSS-compatible) instance by upgrading its specifications to accommodate business growth, or downgrading them to save costs during periods of lower demand.
Billing
The fees for a specification change depends on the billing method of your instance:
Subscription instances: You pay the price difference for an upgrade or receive a refund for a downgrade.
Pay-as-you-go instances: You are billed based on the new specifications.
For more information, see Configuration changes.
Usage notes
You do not need to modify your application code to adapt to the change. The endpoints, database accounts, passwords, and whitelist settings of the instance remain unchanged.
Instance data is preserved. In the rare event that the original primary node fails during switchover, there is a theoretical risk of losing a small amount of unsynchronized data.
For a cloud-native instance, an upgrade or downgrade can be performed without transient disconnections when the server that hosts the instance has sufficient resources. In this case, your services running on the instance are not affected. For more information, see Upgrade or downgrade procedure.
In other cases, such as when the server that hosts the cloud-native instance has insufficient resources or your instance is a classic instance, the instance is migrated to another server for the upgrade or downgrade, which has the following impacts:
One to two transient disconnections, each lasting less than 30 seconds, occur during switchover. Make sure your application can reconnect to the instance after the change.
The instance is read-only for about one minute during the change. This is to ensure fast data synchronization and prevent dual-writes from DNS caching. For instances to which large amounts of data is written, this period may be longer.
During the upgrade or downgrade, the minor version of the instance is automatically upgraded to the latest. Minor versions are backward-compatible, you do not need to worry about compatibility issues.
Limitations
The used memory of the instance cannot exceed 80% of the memory capacity after a downgrade. Otherwise, the downgrade fails. For example, if you have a DRAM-based instance with 2 GB of memory in use, you cannot downgrade its memory to less than 2.5 GB.
All child instances within a distributed instance are limited to having identical specifications. Scaling them to different specifications is not supported and can cause performance issues.
For ESSD-based instances, you can increase the storage capacity in increments of 10 GB, but you cannot decrease it.
Procedure
Log on to the console and go to the Instances page. In the top navigation bar, select the region in which the instance that you want to manage resides. Then, find the instance and click the instance ID.
Navigate to the specification change page.
For a subscription instance: In the upper-right corner, click or Specification Downgrade.
For a pay-as-you-go instance: In the upper-right corner, click in the upper-right corner.
On the page that appears, change the instance specifications. Then, click Buy Now.
Pay attention to the Switching Time parameter during configuration:
Switch after Data Migration: The system immediately switches to the new node after the change.
Switch Within Maintenance Window (Recommended): The system switches to the new node during the maintenance window (off-peak hours). Before the switchover, you can go to the Task Center in the console and click Change Switching Time next to the task to change the switchover time.
Complete the payment as prompted.
After you submit the change request, the instance status immediately changes to Changing Configuration regardless of the Switching Time you selected. The system starts to prepare for the change, such as requesting resources and synchronizing data. This does not affect the services provided by the instance. Transient disconnections occur only when the system switches over to the new node.
FAQ
Can I upgrade only the CPU specifications of an instance?
Appendix: How specification changes work
Cloud-native instance
After you submit a specification change request, the instance enters the Changing Configuration state.
The system checks if the current node hosting the instance has sufficient resources for the target specifications.
The system performs the specification change in one of the two ways:
If the node has sufficient resources, the instance is upgraded or downgraded without transient disconnections. In this case, your services running on the instance are not affected.
If the resources of the node is insufficient, the instance is migrated to a new host:
The system provisions a new host node that meets the target specifications and pre-syncs the data to it.
The system switches the business to the new node within the maintenance window (or immediately). This causes a transient disconnection.
After the specification change is complete, the instance returns to the Running state.
Classic instance
After you submit a specification change request, the instance enters the Changing Configuration state.
The system provisions a new host node that meets the target specifications and pre-syncs the data to it.
The system switches the business to the new node within the maintenance window (or immediately). This causes a brief connection interruption.
After the specification change is complete, the instance returns to the Running state.
