Tair (Redis OSS-compatible) cluster instances can scale to increase or decrease the number of shards without generating the -ASK
and -TRYAGAIN
errors typically seen in native Redis clusters during such operations. This leads to an imperceptible scaling process.
Features
Compared with the scaling solution for native Redis clusters, the imperceptible scaling solution for Tair (Redis OSS-compatible) cluster instances provides the following benefits:
Efficient scaling management: uses a centralized control component to achieve efficient and precise control over cluster behavior.
Atomic data migration: modifies the data replication logic of the kernel to ensure the atomicity of data migration. During the scaling process, data is migrated on a slot-by-slot basis. This approach prevents slot fragmentation and avoids the occurrence of the
-ASK
and-TRYAGAIN
errors that cannot be handled by the application. This greatly improves business stability and user experience.NoteIn the REdis Serialization Protocol (RESP), commands that do not involve data operations such as PING and INFO and special commands such as PUB/SUB and blocking commands cannot be automatically redirected after slot migration. The application layer needs to regularly update the route table to obtain the latest topology after scaling.
To ensure data consistency before and after data migration, the system increases the latency for write requests directed at the involved slot during the final stage of data migration. Despite the increased latency, the write requests will not fail.
Shortened data migration duration: During the scaling process, the imperceptible scaling solution supports slot-based data migration instead of key-based data migration. Compared with key-based data migration, slot-based data migration significantly improves efficiency and effectively shortens the overall data migration duration.
Elastic resource scaling: supports auto scaling to meet resource requirements in different business scenarios.
Applicable scope
Instances deployed in cloud-native mode
Instances of the following editions and versions:
Redis Open-Source Edition 5.0 instances of minor version 5.2.0 or later
Redis Open-Source Edition 6.0 instances of minor version 6.0.2.0 or later
Redis Open-Source Edition 7.0 instances
Tair (Enterprise Edition) DRAM-based instances that are compatible with Redis 5.0 (minor version 5.0.34 or later)
Tair (Enterprise Edition) DRAM-based instances that are compatible with Redis 6.0
Tair (Enterprise Edition) DRAM-based instances that are compatible with Redis 7.0
Precautions
Client requirements:
If the instance is a cluster instance in direct connection mode, the client must be able to properly handle the MOVED command.
If the instance is a cluster instance in proxy mode, specific proxy nodes are released during the scale-in process, which may cause disconnections. In this case, the client must be able to reconnect to the instance.
During the scaling process, increased latency may lead to command timeouts. In this case, the client must be able to reconnect to the instance.
NoteWe recommend that you use a recommended client.
Impacts of special commands:
During scaling operations, blocking commands may result in errors.
During scaling operations, PUB/SUB commands do not ensure consistency and may cause errors based on how the client handles the commands.