You can scale a Tair (Redis OSS-compatible) cluster instance horizontally by adding or removing shards. Adding shards increases the total capacity, connections, and throughput of the instance. Removing shards reduces capacity when your workload no longer requires it. After you change the shard count, the instance automatically rebalances data across the remaining shards. No manual intervention is required.
When to scale
Scale out (add shards) when you observe any of the following:
Data volume is growing and approaching the capacity limits of the current shard configuration.
Read/write traffic is increasing and the current number of shards cannot sustain the required throughput.
Response latency is climbing under normal workloads, indicating resource pressure on the existing shards.
Scale in (remove shards) when:
Instance utilization has been consistently low for an extended period and you want to reduce costs.
You previously scaled out to handle a temporary traffic spike that has subsided.
Scale proactively. Do not wait until the instance is under extreme load, because the scaling process requires resources to rebalance data.
Limits
| Limit | Value |
|---|---|
| Minimum number of shards per instance | 2 |
| Maximum number of shards per instance | 256 |
| Maximum shards added or removed per operation | 64 |
| Classic cluster with direct connection mode enabled | Cannot change the shard count and shard specifications at the same time. For more information, see Configuration change solutions for classic cluster instances. |
Cloud-native cluster vs. classic cluster
Tair cluster instances use one of two management architectures -- cloud-native or classic -- and the scaling process differs significantly between them.
| Aspect | Cloud-native cluster | Classic cluster |
|---|---|---|
| Scaling method | Adds or removes shards in place on the existing instance. | Migrates the entire instance to a new instance with the desired shard count. |
| Process steps | 1. Add or remove shards from the instance. 2. Automatically rebalance data. 3. Configuration change complete. | 1. Create a new instance. 2. Migrate data to the new instance and rebalance. 3. Switch to the new instance at the specified time. 4. Configuration change complete. |
| Simultaneous specification change | No. New shards must have the same specifications as the existing shards. | Yes. You can adjust shard specifications at the same time as the shard count. |
| Availability during scaling | Seamless. No transient connections or read-only states occur during scale-out or scale-in. | One or two transient connections lasting less than 30 seconds may occur during the instance switch. |
| Read-only state | None. | The instance usually enters a read-only state for less than one minute to allow the new instance to catch up with incremental data and to avoid dual writes caused by DNS cache. If the write volume is large, the read-only duration may be longer. |
| Latency | May cause fluctuations in response latency. | N/A (impact occurs during the switch). |
| Minor version | No change. | The system upgrades the minor version of the instance to the latest version. Minor versions are forward-compatible, so you do not need to worry about compatibility issues. |
| Overall impact | Minor impact. The time required depends on the network, task queue, instance workload, and data volume. | Moderate impact due to the transient connections and potential read-only state. |
Costs
Pay-as-you-go instances: After you add or remove shards, the instance is billed based on the new specifications.
Subscription instances: If you add shards, you must pay for the new shards. If you remove shards, you will receive an automatic refund. For more information about costs and the refund policy, see Configuration change fees.
Best practices
Perform changes during off-peak hours. Both cluster types may experience some service impact during scaling. Schedule shard adjustments during periods of low traffic.
Add enough shards at a time (cloud-native cluster). When you add shards, the instance automatically rebalances data. Adding too few shards at a time results in low rebalancing speed and scale-out efficiency. Add at least 1/6 of the current total number of shards in a single operation (rounded up). For example:
8 current shards: add at least 2 (8/6 = 1.33, rounded up to 2).
64 current shards: add at least 11.
100 current shards: add at least 17.
Ensure your application has a reconnection mechanism. For cloud-native clusters, removing a shard forcibly disconnects connections to that shard. For classic clusters, the instance switch causes transient connections. In both cases, your application should handle reconnection gracefully.
Verify capacity before removing shards. Removing shards reduces the total capacity and performance of the instance. Confirm that the remaining shards can handle your data volume and traffic before you proceed.
Use the maintenance window for classic clusters. Perform the adjustment within the maintenance window to control when the instance switch occurs.
Procedures
The following procedures describe how to add or remove shards from both cluster types. All procedures start from the same page:
Log on to the console and go to the Instances page.
In the top navigation bar, select the region in which the instance resides.
Find the instance and click the instance ID.
Then follow the steps for your cluster type below.
Cloud-native cluster: Add shards
Operations are executed immediately in all scenarios. However, for proxy mode instances, you can choose to remove shards within a maintenance window. After you adjust the number of shards, the instance status immediately changes to Adjusting configuration. The specifications of new shards must be the same as those of the existing shards.
In the Shard Information section, click Add Shard.
In the dialog box that appears, set the number of shards and click Pay. Then, complete the payment.
Cloud-native cluster: Remove shards
Removing shards reduces the total capacity and performance of the instance and forcibly disconnects connections to the corresponding shards. Perform this operation with caution. Make sure that your application has a reconnection mechanism before you proceed.
Click Delete Shard in the upper-right corner of the Shard Information section or click Delete in the Actions column corresponding to the shard. If the instance is in proxy mode, you must also select a deletion policy for the proxy nodes. We recommend that you select Update During Maintenance.
Click OK. The shard is removed, and its data is automatically migrated to the other shards.
Classic cluster: Add or remove shards
If direct connection mode is enabled for the instance, you cannot change the number of shards and the shard specifications at the same time. For more information, see Configuration change solutions for classic cluster instances. We recommend that you perform the adjustment within the maintenance window. Before the task is executed, you can go to the Task Center page from the navigation pane on the left of the console, find the task for the instance, and change its execution time.
Adjust the specifications:
For a subscription instance: In the upper-right corner, choose Specification Adjustment > Specification Upgrade or Specification Downgrade.
For a pay-as-you-go instance: In the upper-right corner, choose Specification Adjustment > Specification Upgrade/Downgrade.
On the configuration change page, select the desired configuration and click Buy Now.
Complete the payment.
What to do next
After you submit the configuration change request, the instance status immediately changes to Changing Configuration. This does not affect the services that the instance provides. You can view the task status on the Task Center page.
FAQ
Q: When I add or remove shards, is the data redistributed?
A: Yes. When the number of shards changes, the instance automatically rebalances the data.
For cloud-native cluster instances, the data rebalancing process is optimized at the kernel layer. This allows for fast rebalancing with minimal impact on your services.
For classic cluster instances, the instance switch occurs only after the data is rebalanced on the new instance.
Q: If I remove a shard, is the data lost?
A: No. The data on the removed shard is automatically redistributed to the remaining shards.
Q: If I remove a shard, do I get a refund?
A: Yes. You will receive an automatic refund. For more information about costs and the refund policy, see Configuration change fees.
Q: Can I convert a classic cluster instance to a cloud-native cluster instance?
A: Yes. For more information, see Switch to the cloud-native deployment mode.
Related API operations
| API operation | Description |
|---|---|
| AddShardingNode | Adds a shard to a cloud-native cluster instance. |
| DeleteShardingNode | Removes a shard from a cloud-native cluster instance. |
| ModifyInstanceSpec | Adds or removes shards for a classic cluster instance. |
References
To change shard specifications, see Change instance configurations.