Redis Replication

Replication in Redis means keeping an exact, live copy of your data on one or more additional servers. One server acts as the primary (called the primary or master), and one or more servers act as replicas (called replicas or slaves). Replicas receive every write the primary makes and apply it to stay in sync.

The Newspaper Printing Press Analogy

One journalist writes the news at a central desk (the primary). Multiple printing presses across the city each receive a copy of the final article and print it (the replicas). Every reader gets the same news. If one press breaks down, the others keep printing. Redis replication works the same way.

┌─────────────────────────────────────────────────────┐
│                                                     │
│  Primary Server (writes and reads)                  │
│  ┌──────────────────────────────────┐               │
│  │  SET user:1 "Alice"              │               │
│  │  INCR pageviews                  │               │
│  └────────────┬─────────────────────┘               │
│               │ replication stream                  │
│    ┌──────────┼──────────────┐                      │
│    ▼          ▼              ▼                      │
│  Replica 1  Replica 2    Replica 3                  │
│  (read-only) (read-only) (read-only)                │
│                                                     │
└─────────────────────────────────────────────────────┘

Writes → go to Primary only
Reads  → can go to any Replica (offload the Primary)

Setting Up a Replica

Replication requires no changes to the primary server. You configure the replica.

In the Replica's redis.conf

replicaof 192.168.1.10 6379
# 192.168.1.10 is the Primary's IP address
# 6379 is the Primary's port

Or in redis-cli on the replica:
  REPLICAOF 192.168.1.10 6379

To Stop Replication (Make the Replica Standalone)

  REPLICAOF NO ONE

How Replication Works – Full Sync and Incremental Sync

Initial Full Sync

New replica connects to primary:

  Replica ──── "Hello, I need a sync" ────▶ Primary
               Primary runs BGSAVE
               Creates a snapshot (dump.rdb)
  Replica ◀── receives dump.rdb ──────────── Primary
               Replica loads dump.rdb
               Replica applies any commands that ran during the save

After this, the replica is in sync.

Ongoing Incremental Sync

After full sync, primary sends every write command to replicas:

  Primary: SET score 9000
           ─────────────────▶ Replica 1: applies SET score 9000
           ─────────────────▶ Replica 2: applies SET score 9000

This is asynchronous — the primary does NOT wait for replicas to confirm
before responding to the client. This makes writes fast.

Replication Lag

Because replication is asynchronous, a replica may be a few milliseconds behind the primary. A client that reads from a replica immediately after a write to the primary might see the old value for a brief moment.

Timeline:
  t=0ms: Client writes  SET stock 50  to Primary
  t=0ms: Primary sends replication command to Replica
  t=2ms: Replica applies the command

  t=1ms: Another client reads GET stock from Replica
         → sees "51" (old value) ← replication lag!
  t=3ms: Same read → sees "50" (now in sync)

This is called eventual consistency.
For critical reads (like stock levels during checkout),
always read from the Primary.

Checking Replication Status

Run on the Primary:
  INFO replication

Output (example):
  role:master
  connected_slaves:2
  slave0:ip=192.168.1.11,port=6379,state=online,offset=12345,lag=0
  slave1:ip=192.168.1.12,port=6379,state=online,offset=12345,lag=1

  lag=0 → fully in sync
  lag=1 → 1 second behind (investigate if lag keeps growing)

Read Load Distribution

Replicas accept only read commands. Pointing your app's read traffic at replicas reduces load on the primary.

App architecture with read distribution:

  ┌─────────────┐   writes   ┌──────────────┐
  │     App     │───────────▶│   Primary    │
  │             │            └──────────────┘
  │             │   reads
  │             │───────────▶ Replica 1 (60% of reads)
  │             │───────────▶ Replica 2 (40% of reads)
  └─────────────┘

Primary handles only writes + replication.
Each replica handles a share of reads.
Total read capacity scales with number of replicas.

Replica of a Replica (Cascading Replication)

You can chain replicas to reduce load on the primary:

  Primary
    │
    ├──▶ Replica A
    │        │
    │        ├──▶ Replica A1
    │        └──▶ Replica A2
    │
    └──▶ Replica B

Primary replicates only to Replica A and B.
A and B replicate to their own replicas.
Useful for geographically distributed clusters.

Key Points

  • One primary accepts writes; one or more replicas copy the data and accept reads.
  • Configure a replica by pointing it at the primary with REPLICAOF (in redis.conf or redis-cli).
  • Initial sync sends a full RDB snapshot. After that, the primary streams each write command to all replicas.
  • Replication is asynchronous — replicas may be milliseconds behind. For consistency-critical reads, use the primary.
  • Distribute read traffic across replicas to reduce load on the primary and increase overall throughput.
Previous lessons
Back to courses
Next lessons

Leave a Comment