Mastering Redis Cluster: Step‑by‑Step Setup, Testing, and Failover

Overview

Redis Sentinel provides high‑availability with automatic failover, but all data resides on a single master, limiting capacity and performance for large‑scale workloads. Redis Cluster solves this by partitioning data into 16,384 hash slots and distributing them across multiple nodes, greatly increasing storage capacity, throughput, and fault tolerance.

Cluster Architecture

Each node in a Redis Cluster is responsible for a subset of hash slots. For example, with three nodes the slot allocation might be:

Node A: slots 0‑5500

Node B: slots 5501‑11000

Node C: slots 11001‑16383

Adding or removing nodes simply involves moving a portion of slots between nodes. The cluster also performs health checks and automatic recovery, supporting both high concurrency and high availability.

Environment Setup

On a single server, create separate directories for each instance (ports 7000‑7005) and copy a base redis.conf into each, adjusting the following key parameters:

port 7000                     # port number
cluster-enabled yes          # enable cluster mode
cluster-config-file nodes-7000.conf  # node‑specific config file
cluster-node-timeout 5000    # timeout in ms
protected-mode no
logfile "logfile-7000.log"
requirepass 123456
masterauth 123456
pidfile "redis_7000.pid"

Create the directory structure:

mkdir cluster-test
cd cluster-test
mkdir 7000 7001 7002 7003 7004 7005

Start each instance:

./redis-server ./cluster-test/7000/redis.conf &
./redis-server ./cluster-test/7001/redis.conf &
./redis-server ./cluster-test/7002/redis.conf &
./redis-server ./cluster-test/7003/redis.conf &
./redis-server ./cluster-test/7004/redis.conf &
./redis-server ./cluster-test/7005/redis.conf &

Cluster Creation

Use redis-cli --cluster create to form the cluster, specifying all node addresses and a replica count of 1 (one slave per master):

redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1 -a 123456

After confirming with yes, the tool reports the slot distribution and master‑slave relationships, e.g., master 7000 owns slots 0‑5460, master 7001 owns 5461‑10922, and master 7002 owns 10923‑16383.

Basic Testing

Connect to the cluster with the -c flag to enable cluster routing:

redis-cli -h 127.0.0.1 -p 7000 -c -a 123456

Run simple commands and observe slot redirection:

127.0.0.1:7000> set slogan good
-> Redirected to slot [16191] located at 127.0.0.1:7002
OK
127.0.0.1:7000> get slogan
-> Redirected to slot [16191] located at 127.0.0.1:7002
"good"

Verify slot calculation directly:

127.0.0.1:7000> cluster keyslot hello
(integer) 866
127.0.0.1:7000> cluster keyslot slogan
(integer) 16191

Failover Test

Identify master‑slave pairs with cluster nodes. Stop the master on port 7002; the cluster marks it as master,fail and promotes its slave (port 7003) to master. Restarting the original master makes it a slave of the new master, demonstrating automatic failover.

Cluster Health Check

Run redis-cli --cluster check 127.0.0.1:7000 -a 123456 to confirm slot coverage (all 16,384 slots) and that each master has the expected number of keys and replicas.

Conclusion

Redis Cluster provides strong scalability and high availability through data sharding, making it suitable for large‑scale, high‑concurrency scenarios where Sentinel’s single‑master limitation becomes a bottleneck. Future articles will compare all Redis deployment modes and their trade‑offs.