Skip to main content

Replication

Master-Slave replication​

Redis provides asynchronous replication that allows you to set up one master node and one or more slave (replica) nodes.

The master:

  • Handles all write operations (SET, INCR, DEL, etc.).
  • Propagates data changes to the replicas.

The slaves:

  • Get a copy of the master’s dataset.
  • Keep synchronized with the master by receiving a continuous stream of changes.
  • Can handle read-only queries (GET, MGET, etc.), reducing load on the master.

This model is often used for high availability (HA), load balancing, and data redundancy.

Limitations

  • Asynchronous replication → data may be lost if the master crashes before changes are propagated.
  • Slaves are read-only → writes always go to master.
  • No automatic failover → unless you use Redis Sentinel or Cluster.

How Replication Works in Redis​

  1. Initial Sync

    • When a slave connects to the master, it requests a full synchronization.
    • The master performs a BGSAVE (background save) to create an RDB snapshot.
    • It sends this snapshot to the slave, which loads it into memory.
    • While the snapshot is being sent, the master buffers write commands.
    • After the snapshot is loaded, the master sends the buffered commands to the slave.

  2. Ongoing Replication

    • After the initial sync, the master continuously sends write commands to the slave so it stays up-to-date.
    • This is asynchronous, meaning there could be a slight lag.

  3. Automatic Reconnection

    • If the slave disconnects, it automatically tries to reconnect and resync with the master.

Configuration​

On the Master (redis.conf)

# Master’s config (default)
replica-serve-stale-data yes

On the Slave (redis.conf)

# Point to the master
replicaof 127.0.0.1 6379

Or dynamically in the CLI:

127.0.0.1:6380> REPLICAOF 127.0.0.1 6379

Example Setup​

Let’s say we want 1 master and 2 slaves.

  1. Start Master

    redis-server --port 6379

  2. Start Slaves

    redis-server --port 6380
    redis-server --port 6381

  3. Configure Slaves

    In the Redis CLI:

    127.0.0.1:6380> REPLICAOF 127.0.0.1 6379
    127.0.0.1:6381> REPLICAOF 127.0.0.1 6379

  4. Test Replication

    On master:

    127.0.0.1:6379> SET user:1 "Alice"
    OK

    On slave (port 6380 or 6381):

    127.0.0.1:6380> GET user:1
    "Alice"

    The data written to the master is automatically replicated to the slaves.

Read Replicas in Redis​

A read replica in Redis is simply a replica node (slave) configured to receive data from the master and serve read-only queries.

  • Master: Handles all write operations (e.g., SET, INCR, DEL).
  • Replica: Receives replicated data from the master and can serve read operations (e.g., GET, MGET, HGET).

This improves performance and scalability, since you can distribute read queries across multiple replicas, reducing load on the master.

Key Characteristics of Read Replicas​

  1. Read-only by default

    • By default, replicas are read-only (replica-read-only yes in config).
    • This prevents accidental writes.
    • You can override with CONFIG SET replica-read-only no, but it breaks consistency.

  2. Asynchronous Replication

    • Replicas might be slightly behind the master (called replication lag).

  3. Scaling Reads

    • Applications can direct read-heavy traffic (like analytics or reporting queries) to replicas.

  4. High Availability

    • If the master goes down, replicas can be promoted to master (manually, or automatically via Sentinel).

Limitations of Read Replicas​

  • Replication Lag: Replicas may serve slightly outdated data compared to the master.
  • No Writes Allowed: You cannot perform writes on replicas unless explicitly allowed.
  • Manual Promotion: By default, replicas don’t automatically take over as master (requires Sentinel or Cluster).

Redis Sentinel for Failover​

Redis Sentinel is a distributed system that provides:

  1. Monitoring

    • Keeps track of whether the master and replicas are working properly.

  2. Notification

    • Alerts administrators or external systems when something goes wrong.

  3. Automatic Failover

    • If the master is not reachable, Sentinel promotes one of the replicas to master and reconfigures the other replicas to follow it.

  4. Configuration Provider

    • Applications can query Sentinel to know the current master’s address (no need to hardcode the master IP).

Why Sentinel?​

  • Normal master-replica setup gives redundancy but requires manual intervention when the master fails.
  • Sentinel automates failover, ensuring high availability with minimal downtime.
  • Useful for production deployments where availability is critical.

How Sentinel Works​

  1. Monitoring

    • Each Sentinel constantly checks the health of the master and replicas via PINGs.

  2. Failure Detection

    • If a master doesn’t respond within a configured time (down-after-milliseconds), the Sentinel marks it as subjectively down.
    • Other Sentinels must agree to mark it objectively down (majority vote).

  3. Failover

    • Sentinels elect a leader.
    • The leader promotes one replica to master.
    • Other replicas are reconfigured to follow the new master.
    • Applications connected through Sentinel will automatically discover the new master.

Sentinel Configuration Example​

Suppose we have:

  • Master → Port 6379
  • Replicas → Ports 6380, 6381
  • Sentinels → Ports 26379, 26380, 26381

  1. Configure Redis Master

    # redis-master.conf
    port 6379

  2. Configure Replicas

    # redis-slave.conf (for each replica)
    port 6380
    replicaof 127.0.0.1 6379

  3. Configure Sentinel

    Create a sentinel.conf:

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

    Explanation:

    • mymaster → Name of monitored master.
    • 127.0.0.1 6379 → Master’s address and port.
    • 2 → Number of Sentinels that must agree master is down.
    • down-after-milliseconds → Time after which a master is considered down (5s).
    • failover-timeout → Max time for failover (10s).
    • parallel-syncs → Number of replicas syncing with new master at once.

  4. Start Components

    redis-server redis-master.conf
    redis-server redis-slave.conf --port 6380
    redis-server redis-slave.conf --port 6381
    redis-sentinel sentinel.conf --port 26379
    redis-sentinel sentinel.conf --port 26380
    redis-sentinel sentinel.conf --port 26381

Example Walkthrough of Sentinel​

  1. Normal Operation

    • Master: 6379
    • Replicas: 6380, 6381
    • Sentinels monitor the master.

  2. Insert Data

    127.0.0.1:6379> SET user:1 "Alice"
    OK

    Check replica:

    127.0.0.1:6380> GET user:1
    "Alice"

  3. Simulate Failure

    Stop the master:

    pkill -f "redis-server.*6379"

  4. Failover Happens

    • Sentinels detect master is down after 5 seconds.
    • They vote and promote one replica (say 6380) as new master.
    • Other replica (6381) is reconfigured to follow 6380.

    Check with Sentinel:

    redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster
    1) "127.0.0.1"
    2) "6380"

    The master has changed automatically!

  5. Client Auto-Discovery

    Applications can connect to Sentinel to always find the current master:

    redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster

    This avoids hardcoding the master’s address in the app.

Redis Cluster​

Redis Cluster is Redis’s built-in distributed solution that provides:

  1. Automatic Sharding (Data Partitioning)

    • Splits the dataset across multiple nodes.
    • Each node holds only part of the data.

  2. High Availability with Replication

    • Each shard (master) can have replicas.
    • If a master fails, a replica is promoted automatically.

  3. No Single Point of Failure

    • Cluster survives as long as the majority of masters are available.

Sharding in Redis Cluster​

Instead of storing all keys on one master, Redis Cluster divides the keyspace into 16384 hash slots.

  • Each master node is responsible for a subset of slots.
  • When a client issues a command, Redis determines the slot for the key using CRC16 hashing:
HASH_SLOT = CRC16(key) mod 16384
  • That slot tells Redis which node holds the key.

Example:

  • Key user:1 → Slot 5798
  • Key user:2 → Slot 15296

If you have 3 masters, Redis divides 16384 slots across them (roughly ~5461 slots each).

Hash Slots​

  • 16384 slots → fixed, not configurable.
  • Each master manages some slots.
  • Replicas mirror their master’s slots (but are read-only).
  • During rebalancing, slots can be moved between masters.

This makes scaling horizontal:

  • Add a new master → some slots are migrated to it.

Replication in Cluster​

Each master has at least one replica:

  • If master fails → a replica is promoted.
  • Ensures high availability with automatic failover.

Example Setup of Cluster (3 Masters, 3 Replicas)​

We want a 6-node cluster:

  • 3 Masters: ports 7000, 7001, 7002
  • 3 Replicas: ports 7003, 7004, 7005
  1. Start Nodes
redis-server --port 7000 --cluster-enabled yes --cluster-config-file nodes-7000.conf --cluster-node-timeout 5000 --appendonly yes
redis-server --port 7001 --cluster-enabled yes --cluster-config-file nodes-7001.conf --cluster-node-timeout 5000 --appendonly yes
redis-server --port 7002 --cluster-enabled yes --cluster-config-file nodes-7002.conf --cluster-node-timeout 5000 --appendonly yes
redis-server --port 7003 --cluster-enabled yes --cluster-config-file nodes-7003.conf --cluster-node-timeout 5000 --appendonly yes
redis-server --port 7004 --cluster-enabled yes --cluster-config-file nodes-7004.conf --cluster-node-timeout 5000 --appendonly yes
redis-server --port 7005 --cluster-enabled yes --cluster-config-file nodes-7005.conf --cluster-node-timeout 5000 --appendonly yes

  1. 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
  • --cluster-replicas 1 → Each master will have one replica.
  • Redis will automatically assign slots across the 3 masters.

Example Walkthrough​

  1. Check Cluster Info

    redis-cli -c -p 7000 cluster info

  2. Check Slot Assignment

    redis-cli -c -p 7000 cluster slots

    Example output:

    0-5460       -> 7000 (master), 7003 (replica)
    5461-10922   -> 7001 (master), 7004 (replica)
    10923-16383  -> 7002 (master), 7005 (replica)

  3. Insert a Key

    redis-cli -c -p 7000 SET user:1 "Alice"

    The client will:

    • Compute slot for user:1 (e.g., 5798).
    • Redirect request to the correct master (7001).

    With -c (cluster mode), redis-cli automatically follows redirects.

  4. Read a Key

    redis-cli -c -p 7002 GET user:1
    "Alice"

    Even though you connected to 7002, the client redirects you to the correct node.

Benefits of Redis Cluster​

  • Horizontal scaling → Distributes data across multiple nodes.
  • High availability → Failover handled by replicas.
  • No single point of failure (if majority of masters remain).
  • Auto rebalancing of slots when nodes are added/removed.

Limitations of Redis Cluster​

  • Cross-slot operations: Multi-key operations must be in the same slot (use hash tags like {user}:1 and {user}:2).
  • Strong network requirements: All nodes must communicate with each other.
  • Higher complexity than standalone/sentinel setups.