Imperceptible scaling

Attribute description

Compared to native Redis cluster scaling, Tair (Redis OSS-compatible) cluster instances offer the following advantages:

• Efficient scaling management: employs a centralized control component for precise cluster behavior management.

• Atomic data migration: modifies the kernel's replication logic to ensure atomic data migration. During scaling, data is migrated by slot, preventing slot splitting and avoiding errors such as -ASK and -TRYAGAIN, thus enhancing business stability and user experience.

  Note

  • In the RESP cluster protocol, commands like PING and INFO, along with special commands such as PUB/SUB and BLOCKING, cannot be automatically redirected after slot migration. The application layer should periodically update the route table to access the latest topology after scaling.

  • To maintain data consistency, write request latency to the corresponding slot may increase during the final stage of data migration, but requests will not fail.

• Reduced data migration time: uses slot-based data migration for improved efficiency over key-based methods, significantly reducing the duration of data migration.

• Elastic resource scaling: supports flexible scaling to accommodate varying business needs.

Applicable instances

• The instance deployment mode is Cloud-native version.

• Suitable for the following instance versions:

  • Redis open-source version 5.0 instances (minor version 5.2.0 and above)

  • Redis open-source version 6.0 instances (minor version 6.0.2.0 and above)

  • Redis open-source version 7.0 instances

  • Tair (Enterprise Edition) memory type compatible with Redis 5.0 version (minor version 5.0.34 and above)

  • Tair (Enterprise Edition) memory type compatible with Redis 6.0 version

  • Tair (Enterprise Edition) memory type compatible with Redis 7.0 version

Precautions

• Client Requirements:

  • If the instance is a cluster instance in direct connection mode, the client must handle the MOVED command correctly.

  • If the instance is a cluster instance in proxy mode, some proxy nodes may be released during scale-in, leading to disconnections. The client should be capable of reconnecting after disconnection.

  • High latency during scaling may cause client command timeouts. The client should be able to reconnect after a timeout.

  Note

  It is recommended to use the recommended client.

• Impact of Special Commands:

  • Blocking commands may result in errors during scaling operations.

  • Pub/sub commands do not guarantee consistency during scaling operations and may cause errors depending on the client's handling of the commands.