Mastering Redis High Availability: Replication, Sentinel, and Cluster Deep Dive

Overview

Redis offers three core architectures that address high availability, scalability, and data safety: simple master‑slave replication, Sentinel‑based automatic failover, and the native Redis Cluster with sharding and automatic failover.

1. Master‑Slave Replication

The basic replication model consists of one master node handling all write operations and one or more read‑only slave nodes that asynchronously copy data from the master.

All writes go to the master.

Slaves replicate data via the SYNC command.

During the initial sync the master creates an RDB snapshot with BGSAVE, sends it to the slave, and buffers subsequent writes in repl_backlog.

After the snapshot is loaded, replication becomes continuous and asynchronous.

Replication modes

Full sync : master sends a complete RDB file (used when a new slave joins or after a reconnection).

Partial sync : incremental sync based on the offset stored in repl_backlog (quick recovery after a temporary network glitch).

Asynchronous : default mode; the master does not wait for slave acknowledgments, offering higher performance at the risk of minor data loss.

Pros

Provides data backup.

Enables read‑write separation.

Simple architecture, easy to deploy.

Cons

Manual failover required when the master crashes.

Write throughput limited by a single master.

Storage capacity bounded by a single machine.

Asynchronous replication can cause temporary inconsistency.

Typical use cases

Small‑scale caches.

Read‑heavy, write‑light workloads.

Foundational layer for Sentinel or Cluster deployments.

2. Sentinel Mode

Sentinel adds automatic high‑availability on top of replication by monitoring master and slave nodes, detecting failures, and performing leader election.

Sentinels periodically ping master and slaves.

If a master does not respond, a sentinel marks it as "subjectively down".

When a quorum of sentinels agrees, the master is marked "objectively down".

Sentinels run a Raft‑like election to choose a leader.

The leader promotes one slave to master, notifies other slaves, and updates client connection info.

Configuration example ( sentinel.conf)

# sentinel.conf core example
port 26379
sentinel monitor mymaster 192.168.10.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
sentinel parallel-syncs mymaster 1

Start the sentinel process: redis-sentinel /etc/redis/sentinel.conf Pros

Automatic failover within seconds.

Failover is transparent to clients.

Read capacity can be scaled horizontally.

Cons

Write and storage limits remain those of a single master.

Requires at least three sentinel instances to avoid split‑brain scenarios.

Potential "brain split" if network partitions occur (mitigated by proper quorum settings).

Practical advice

Deploy a minimum of three sentinel nodes on separate physical machines.

Use client libraries that support Sentinel (e.g., Lettuce, JedisSentinelPool).

3. Redis Cluster

Redis Cluster is the official native distributed solution that provides automatic sharding and automatic failover.

The keyspace is divided into 16,384 slots.

Each master node owns a subset of slots; each master has one or more replica slaves.

Clients compute the slot for a key using CRC16(key) % 16384 and route the request to the appropriate node.

If a key is sent to the wrong node, the server replies with MOVED and the client redirects or caches the slot mapping.

When a master fails, its replica is automatically promoted.

Cluster creation example (six nodes, three masters with one replica each):

# Start six instances (3 masters, 3 slaves)
redis-server redis-7000.conf
redis-server redis-7001.conf
redis-server redis-7002.conf
redis-server redis-7003.conf
redis-server redis-7004.conf
redis-server redis-7005.conf
# Create the cluster
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

Common issues and fixes

Non‑contiguous slots : run redis-cli --cluster fix to rebalance.

Cross‑slot transaction errors : use hash tags {...} to force keys into the same slot.

Split‑brain : adjust cluster-node-timeout to a suitable value.

Uneven data after scaling : run redis-cli --cluster rebalance or --cluster reshard to migrate slots.

Pros

Automatic failover.

Linear write and storage scaling.

Officially supported with a rich ecosystem.

Cons

Deployment and maintenance are more complex.

Only database 0 is supported.

Cross‑slot transactions are limited.

Practical advice

Start with at least 3 masters and 3 replicas.

Keep inter‑node latency below 1 ms.

Use client libraries that understand the Cluster protocol (Lettuce, Redisson, JedisCluster).

4. Performance & Latency Comparison

Write latency : lowest for plain replication and Sentinel; slightly higher for Cluster due to routing overhead.

Read throughput : replication and Sentinel allow read‑scaling; Cluster achieves the highest throughput with multiple masters.

Failover time : manual minutes for replication, automatic seconds for Sentinel and Cluster.

Scaling complexity : simple for replication, moderate for Sentinel, high for Cluster (slot migration required).

Consistency : all three provide eventual consistency.

5. Architecture Selection Guidance

Learning, testing, small caches – use simple master‑slave replication.

Medium‑size services with low write pressure needing HA – choose Sentinel.

Large‑scale, high‑concurrency distributed applications – adopt Redis Cluster.

6. Conceptual Takeaways

The three Redis architectures illustrate the classic trade‑offs in distributed system design:

Replication : maximizes performance and simplicity but lacks automation.

Sentinel : adds automatic failover, improving availability.

Cluster : combines high availability with horizontal scalability through sharding.

According to the CAP theorem, Redis opts for high availability + eventual consistency rather than strict consistency.