When your Tair (Redis OSS-compatible) cluster experiences memory pressure, CPU or network bottlenecks, or over-provisioned capacity, you can scale out to add shards or scale in to remove shards. Unlike open source Redis clusters, Tair eliminates the -ASK and -TRYAGAIN errors that typically occur during slot migration, so your application continues serving requests without interruption.
How it works
Tair modifies the kernel's data replication logic to migrate data on a slot-by-slot basis rather than key by key. A centralized control component manages the process, preventing slot splitting and ensuring that each slot migration is atomic. Slot-level migration completes significantly faster than key-level migration and removes the transient -ASK and -TRYAGAIN redirection errors that clients would otherwise receive.
During the final stage of each slot migration, write request latency for the affected slot increases temporarily. Write requests do not fail.
In the Redis Serialization Protocol (RESP) for clusters, non-data commands such as PING and INFO, and special command families such as PUB/SUB and BLOCKING, are not automatically redirected after a slot migration. The application layer must periodically update the route table to retrieve the latest topology after scaling.
Key capabilities
| Capability | Description |
|---|---|
| Efficient scaling management | A centralized control component provides efficient and precise control over cluster behavior. |
| Atomic data migration | Each slot is migrated atomically. No slot splitting occurs, and clients never receive -ASK or -TRYAGAIN errors. |
| Faster migration | Slot-by-slot migration completes significantly faster than key-by-key migration. |
| Auto Scaling | Tair supports Auto Scaling to handle fluctuating workloads without manual intervention. |
Supported instances
Seamless scaling requires:
Deployment mode: cloud-native
Architecture: cluster
The following instance versions are supported:
| Instance type | Supported versions |
|---|---|
| Redis Open-Source Edition 5.0 | Minor version 5.2.0 or later |
| Redis Open-Source Edition 6.0 | Minor version 6.0.2.0 or later |
| Redis Open-Source Edition 7.0 | All versions |
| Tair (Enterprise Edition) memory-optimized, Redis 5.0-compatible | Minor version 5.0.34 or later |
| Tair (Enterprise Edition) memory-optimized, Redis 6.0-compatible | All versions |
| Tair (Enterprise Edition) memory-optimized, Redis 7.0-compatible | All versions |
| Tair (Enterprise Edition) persistent memory-optimized | All versions |
| Tair (Enterprise Edition) disk-based | All versions |
Before you scale
Client requirements
Configure your client to handle the following behaviors before initiating a scaling operation:
| Connection mode | Behavior to handle |
|---|---|
| Direct connection mode | The client must handle the MOVED command correctly. |
| Proxy mode | Some proxy nodes are released during scale-in, causing connections to drop. The client must reconnect automatically. |
| During scaling (any mode) | High latency may cause command timeouts. The client must reconnect automatically after a timeout. |
Use a recommended client to avoid compatibility issues.
Special command behavior
Avoid using the following command types during a scaling operation:
| Command type | Behavior during scaling |
|---|---|
| Blocking commands | May cause errors. |
| Pub/Sub commands | Does not guarantee data consistency and may cause errors, depending on the client implementation. |