Learning Redis - Replication (Master-Replica) & Redis Sentinel

#Introduction

So far you've been managing a single Redis instance. But production applications need more: data must survive when a single node dies, and read load must be spread out. Episode 12 answers both with replication and Redis Sentinel.

Replication gives you data copies (replicas) for read scaling and backup. Sentinel adds automation: if the master dies, Sentinel promotes one of the replicas to a new master without human intervention. This is the high availability foundation before stepping into Redis Cluster in episode 13.

#Redis Replication

#The Master-Replica Concept

Replication is the asynchronous copying of data from one master (read/write) to one or more replicas (read-only). Applications write to the master; replicas follow the changes continuously. The benefit is twofold: read scaling (replicas handle read load) and data safety (copies always ready).

               ┌────────────┐
application ──>│   master   │──> replica 1 (read-only)
               └────────────┘──> replica 2 (read-only)

#Connecting a Replica with REPLICAOF

A single configuration line connects a replica to the master:

redis-cli REPLICAOF 192.168.1.10 6379
redis-cli INFO replication

redis-cli REPLICAOF 192.168.1.10 6379 makes the current instance a replica of the master at 192.168.1.10:6379. INFO replication shows the role (role:slave or role:master) and sync status. To return to being an independent master, use REPLICAOF NO ONE.

On first connection, the replica performs a full resync: the master takes an RDB snapshot and sends it to the replica, then streams subsequent changes. After that, changes flow continuously (incremental sync).

#Read Scaling

Because replicas are read-only, applications can route read queries to replicas and write only to the master:

redis-cli -p 6380 ROLE

redis-cli -p 6380 ROLE shows the role of the node on port 6380. Important rule: replicas reject write commands — SET on a replica errors with READONLY. Heavy read load is distributed, while the master focuses on serving writes.

#Redis Sentinel

#Sentinel as a Watchdog

Sentinel is a separate process that monitors masters and replicas: checking their health, reporting status, and — most importantly — performing automatic failover. Sentinel uses a gossip protocol and voting among Sentinels to avoid false positives: failover only happens if a majority of Sentinels agree the master is in trouble.

         Sentinel A ──┐
         Sentinel B ──┼── monitors master & replicas
         Sentinel C ──┘
              │ master down
              ▼
         promote replica → new master

#Automatic Failover

When the master is judged dead by a majority of Sentinels, this sequence happens automatically:

1. Sentinel marks the master unhealthy (after down-after-milliseconds and quorum are reached).
2. Sentinel chooses the best replica (the most synchronized) and promotes it via REPLICAOF NO ONE.
3. The other replicas are redirected to the new master.
4. Applications are directed (via Sentinel) to use the new master.

#Setting Up Sentinel

Sentinel runs as a separate daemon with its own configuration file:

sentinel monitor mymaster 192.168.1.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
sentinel parallel-syncs mymaster 1

sentinel monitor mymaster 192.168.1.10 6379 2 tells Sentinel to monitor a master named mymaster, with a quorum of 2 (2 out of 3 Sentinels are needed to declare failover). Run it with:

redis-server sentinel.conf --sentinel

redis-server sentinel.conf --sentinel starts Sentinel in sentinel mode. For proper tolerance, deploy at least 3 Sentinels on separate hosts — with a quorum of 2, one Sentinel dying doesn't stop failover.

#Applications Connecting to Sentinel

Applications don't need to hardcode the master address. Modern Redis libraries support connecting via Sentinel: provide a list of Sentinel addresses and the master name, and the library automatically discovers the active master — when a failover happens, applications switch over without a restart.

#Summary

Episode 12 equipped you with replication for read scaling and Sentinel for high availability: REPLICAOF to connect a replica, INFO replication for verification, then Sentinel with sentinel monitor and automatic failover when the master goes down.

Key takeaways:

• Asynchronous replication: master serves writes, replicas serve reads.
• REPLICAOF <ip> <port> turns a node into a replica; REPLICAOF NO ONE reverts it.
• Replicas reject writes — applications must separate the read and write paths.
• Sentinel monitors the master and performs automatic failover.
• Failover requires a majority of Sentinels — deploy at least 3 instances.
• Modern Redis libraries can use Sentinel as service discovery.

In the next episode, episode 13, we cover Redis Cluster — horizontal scalability with automatic sharding into 16,384 hash slots. You'll learn when you need a cluster, the 6-node setup, and hash tags for multi-key operations. This is the highest level of Redis architecture!