Upgrade or downgrade instance types

What stays the same

When you change specifications, the following remain unchanged — no application code changes are required:

• Endpoints

• Database accounts and passwords

• Whitelist settings

Instance data is preserved. In the rare case where the primary node fails during switchover, a small amount of unsynchronized data may be lost. As a precaution, create a manual backup before you change specifications.

Changing specifications (whether scaling up or scaling down) does not directly affect CPU utilization, the number of client connections, throughput, or cache hit rate — these metrics are determined by your actual workload, not by the specification tier.

Service impact

Both scale-up (upgrades) and scale-down (downgrades — including downgrades that reduce only node memory) can trigger a host migration when the current host cannot accommodate the target specifications. A migrated switchover is not seamless: it causes 1–2 brief connection interruptions and approximately 1 minute of read-only state. Only Cloud-native cluster instances and Cloud-native standard instances on hosts with sufficient resources complete the change in-place without any downtime.

When a switchover occurs, the instance is also read-only for about one minute to ensure fast data sync and prevent dual-write issues caused by DNS caching. For instances with high write volumes, this period may be longer.

During the change, the minor version of your instance is automatically upgraded to the latest. Minor versions are backward-compatible.

Configuration change duration

The overall duration of a configuration change consists of two phases:

• Backend preparation: The system provisions new nodes of the target specification and synchronizes data. This may take from tens of minutes to several hours depending on the data volume. During this phase, the instance continues to serve requests normally and business is not affected.

• Switchover: After preparation completes, traffic switches to the new nodes. Cloud-native cluster instances and standard instances with sufficient resources switch over transparently; in other cases, 1-2 transient disconnections of less than 30 seconds each occur.

Therefore, the total configuration change duration (tens of minutes to several hours) and the business impact duration (less than 30 seconds, or none) are two different concepts. You can track progress in the Task Center of the console.

Steps

1. Log in to the Instances page. In the top navigation bar, select the region where your instance resides, then click the instance ID.

2. In the upper-right corner, click Specification Adjustment, then select the appropriate option:

   • Subscription instance: Select Specification Upgrade or Specification Downgrade.

   • Pay-as-you-go instance: Select Specifications Upgrade/Downgrade.

3. On the page that appears, select the target specifications.

4. Set the Switching Time:

   • Switch During the Maintenance Window: The system applies the change during the configured maintenance window (off-peak hours). To adjust the timing before the switchover, go to Task Center and click Change Switching Time next to the task.

   • Switch Immediately After Data Migration: The system switches to the new node immediately after data migration completes.

5. Click Create Now and complete the payment.

After you submit, the instance status changes to Changing Configuration. The system begins requesting resources and syncing data in the background — your services are not affected at this stage. Transient disconnections only occur at the moment of switchover to the new node.

Can I upgrade only the CPU without changing memory?

No. Tair (including Redis Open-Source Edition) does not support upgrading CPU independently. To increase available CPU cores, use one of the following approaches:

• Switch from standard to cluster architecture, or enable read/write splitting.

• Add read-only nodes (for instances with read/write splitting enabled).

• Add shards (for cluster instances).

For more details, see How to upgrade the CPU specifications of an instance and Instance types and FAQ.

What should I consider before changing specifications when memory usage is high?

If you plan to scale down and your current memory usage is high, first verify that the target specification satisfies the constraint: new memory capacity × 0.8 > currently used memory. If this condition is not met, the scale-down fails and the original configuration is retained — no data is lost.

If you plan to scale up to address persistently high memory usage, consider first investigating the root cause. Reducing unnecessary data (for example, by cleaning up unused keys, setting TTL policies, or tuning the eviction policy) can lower memory consumption and may allow you to defer or avoid an upgrade. For a systematic troubleshooting approach, see Troubleshoot high memory usage.