← Blogs

Redis High Availability

References: Redis replication, Sentinel, and Redis Cluster.

Primary–Replica Replication

Replication provides copies of data and can serve reads from replicas. A primary accepts writes and sends updates to its replicas. Replication is asynchronous, so a replica can lag behind a successful write.

Redis replication

Full Synchronization

  1. A replica connects to a primary and requests synchronization with PSYNC.
  2. If a partial sync is impossible, the primary responds with FULLRESYNC, including its replication ID and offset.
  3. The primary produces an RDB snapshot and sends it to the replica while buffering subsequent writes.
  4. The replica loads the snapshot and applies the buffered updates, then continues receiving the replication stream over a long-lived connection.

To configure a replica, use REPLICAOF <primary-host> <primary-port>. A full sync consumes network and CPU resources; replicas can also replicate from other replicas to reduce load on the primary.

Partial Synchronization

After a short disconnection, the replica reconnects with its replication ID and offset. If the missing updates are still in the primary’s circular replication backlog, the primary sends only those updates. Otherwise, it performs a full sync. The backlog’s size is configurable, so a larger backlog can accommodate longer interruptions at a memory cost.

Reading from Replicas

Because replication is asynchronous, a read from a replica can return stale data. Applications that require read-after-write behavior must route those reads appropriately or use a stronger application-level strategy. Replication offsets and INFO replication help monitor lag.

Redis Sentinel

Sentinel monitors a primary and its replicas and coordinates automatic failover for deployments that do not use Redis Cluster.

Detecting a Failure

Each Sentinel checks whether a primary responds within down-after-milliseconds. One Sentinel can mark it subjectively down. When the configured quorum agrees, the primary is marked objectively down. Starting an actual failover also requires authorization from a majority of Sentinels.

Failover

  1. Sentinels elect a leader to coordinate the failover.
  2. The leader selects an eligible replica, considering connectivity, replica-priority, replication offset, and run ID. Lower nonzero priorities are preferred; priority 0 prevents promotion.
  3. The selected replica is promoted with REPLICAOF NO ONE.
  4. Other replicas are reconfigured to follow the new primary. When the old primary returns, it can be reconfigured as a replica.
  5. Clients can ask Sentinel for the current primary address or subscribe to its notifications.

Quorum and majority voting help prevent a minority partition from promoting a competing primary. They do not make replication synchronous: acknowledged writes can still be lost during failover.

Redis Cluster

Cluster distributes keys across 16,384 hash slots. A key’s slot is based on CRC16(key) mod 16384, with hash tags providing a way to place related keys in the same slot. Each primary owns a subset of slots and can have replicas.

Adding a Node

Nodes meet through the cluster protocol and exchange state through gossip. Adding a primary also requires moving some hash slots and their keys to it; removing one requires moving its slots away first. Cluster clients discover slot ownership and redirect requests when the mapping changes.

Failures and Consistency

Replicas can be promoted when their primary fails. Nodes exchange failure information, and a majority of primaries is required for failover. Replication is asynchronous, so Redis Cluster does not guarantee strong consistency or zero lost writes during a failure.

If a network partition leaves a primary unable to reach the majority for long enough, it stops accepting writes. This limits the time in which two sides of a partition can diverge.