Replication Commands
REPLICAOF-&-INFO-REPLICATION
Redis replication creates copies of your data on replica servers. Read scaling, high availability, and data safety - all from asynchronous replication.
You'll Learn
- Setting up replication with REPLICAOF
- Monitoring with INFO REPLICATION
- Understanding replication lag
- Failover considerations
Free Download
See Your Data, Not Terminal Text
Redimo visualizes every Redis data type beautifully. Edit inline, undo mistakes, stay safe in production.
1. How Redis Replication Works
Redis replication is asynchronous master-replica. The master accepts writes, replicas follow behind, receiving a stream of commands to execute.
┌─────────────┐ writes ┌─────────────┐
│ Clients │ ───────────────▶│ Master │
└─────────────┘ └──────┬──────┘
│
replication │ stream
│
┌────────────────────────┼────────────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Replica 1 │ │ Replica 2 │ │ Replica 3 │
└─────────────┘ └─────────────┘ └─────────────┘
│ │ │
▼ ▼ ▼
reads only reads only reads onlyAsynchronous = Lag
Replication is async. Writes acknowledged by master may not yet be on replicas. For most use cases this is fine. For strict consistency, you'll need WAIT command or architectural changes.
2. REPLICAOF: Setup Replication
Run REPLICAOF on a Redis instance to make it a replica of another.
Enable Replication
# On the replica server
REPLICAOF 192.168.1.10 6379
OK
# Replica will:
# 1. Connect to master
# 2. Request full sync (RDB transfer)
# 3. Load RDB
# 4. Start receiving command stream
# Check status
INFO replication
# role:slave
# master_host:192.168.1.10
# master_port:6379
# master_link_status:upStop Replication
# Promote replica to standalone master
REPLICAOF NO ONE
OK
# Now accepts writes
# Useful for failover
# Note: Old command SLAVEOF still works but deprecated
SLAVEOF NO ONE # Same as REPLICAOF NO ONE3. INFO REPLICATION: Monitor Status
INFO REPLICATION shows complete replication state - different output for master vs replica.
On Master
127.0.0.1:6379> INFO replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.1.11,port=6379,state=online,offset=123456,lag=0
slave1:ip=192.168.1.12,port=6379,state=online,offset=123400,lag=1
master_replid:8371445fedcba9876543210abcdef12345678901
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:123456
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:123456On Replica
127.0.0.1:6379> INFO replication
# Replication
role:slave
master_host:192.168.1.10
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:123456
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:8371445fedcba9876543210abcdef12345678901
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:123456
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:1234564. Key Replication Metrics
master_link_status
up- Connected and syncingdown- Disconnected from master
lag (on master's slave info)
0-1- Healthy, near real-time>5- Falling behind, investigate>60- Severely lagging
master_sync_in_progress
0- Normal streaming replication1- Full sync in progress (RDB transfer)
Offset Comparison
Compare master_repl_offset on master with slave_repl_offset on replicas. Difference = replication lag in bytes.
5. Replication Backlog
The backlog is a circular buffer of recent commands. When a replica reconnects, it can partial-sync from the backlog instead of full-sync.
Configure Backlog
# Check current size
CONFIG GET repl-backlog-size
1) "repl-backlog-size"
2) "1048576" # 1MB default
# Increase for unreliable networks
CONFIG SET repl-backlog-size 104857600 # 100MB
# How long to keep backlog after last replica disconnects
CONFIG GET repl-backlog-ttl
1) "repl-backlog-ttl"
2) "3600" # 1 hour
# In INFO replication:
# repl_backlog_histlen shows current content size
# repl_backlog_first_byte_offset shows oldest offset availableSizing the Backlog
If replicas frequently need full-sync after brief disconnections, increase the backlog. It should be large enough to hold commands generated during typical network blips (write rate × expected disconnect duration).
6. WAIT: Synchronous Replication
WAIT blocks until N replicas have acknowledged writes. Use when you need stronger consistency guarantees.
Using WAIT
# Write some data
SET important-key "critical-value"
# Wait for 2 replicas to acknowledge, up to 1 second
WAIT 2 1000
(integer) 2 # 2 replicas acknowledged
# If timeout expires, returns number that did acknowledge
WAIT 3 1000
(integer) 2 # Only 2 acknowledged before timeout
# WAIT 0 returns immediately with current count
WAIT 0 0
(integer) 2WAIT Trade-offs
WAIT adds latency to writes (waiting for replica acknowledgment). Use selectively for critical data, not for every write. Also note: WAIT guarantees replica received the command, not that the replica won't fail before persisting.
7. Read-Only Replicas
Replica Write Protection
# By default, replicas are read-only
# On replica:
SET test "value"
(error) READONLY You can't write against a read only replica.
# Check setting
CONFIG GET replica-read-only
1) "replica-read-only"
2) "yes"
# Can disable (not recommended)
CONFIG SET replica-read-only no
# Now replica accepts writes (will be lost on next sync!)8. Monitoring Checklist
Health Check Script
# On master - check all replicas connected
INFO replication | grep connected_slaves
# connected_slaves:2
# Check individual replica lag
INFO replication | grep lag
# slave0:...,lag=0
# slave1:...,lag=1
# On replica - check connection to master
INFO replication | grep master_link_status
# master_link_status:up
# Check if sync in progress
INFO replication | grep master_sync_in_progress
# master_sync_in_progress:0
# Calculate replication lag in bytes
# master_repl_offset - slave_repl_offsetAlert Thresholds
- •
master_link_status:down- Alert immediately - •
lag > 10- Warning - •
master_sync_in_progress:1for >5min - Investigate - •
connected_slavesdrops - Alert
9. Failover
Manual Failover Steps
# 1. Stop writes to master (or it's already down)
CLIENT PAUSE 60000 WRITE # If master is reachable
# 2. Wait for replica to catch up (check offset)
# On replica:
INFO replication | grep slave_repl_offset
# 3. Promote replica
# On the replica you want to promote:
REPLICAOF NO ONE
OK
# 4. Redirect application traffic to new master
# 5. (Optional) Make old master a replica of new master
# On old master (when it comes back):
REPLICAOF <new-master-ip> 6379Automated Failover
For production, use Redis Sentinel or Redis Cluster for automated failover. Manual failover is error-prone and slow. Sentinel monitors masters and automatically promotes replicas when master fails.
10. Configuration Best Practices
Recommended Settings
# On master - redis.conf
min-replicas-to-write 1 # Require at least 1 replica
min-replicas-max-lag 10 # Replica must be within 10s lag
repl-backlog-size 100mb # Larger backlog for stability
# On replica - redis.conf
replicaof 192.168.1.10 6379
replica-read-only yes
replica-serve-stale-data yes # Serve data even during sync
replica-priority 100 # Lower = higher priority for SentinelQuick Reference
| Command | Purpose |
|---|---|
REPLICAOF host port | Make this server a replica |
REPLICAOF NO ONE | Promote to master |
INFO replication | Replication status |
WAIT numreplicas timeout | Wait for replica acknowledgment |
PSYNC | Internal - partial sync request |
Monitor Your Replicas
Replication is your safety net. Monitor it closely with Redimo.
Download Redimo - It's Free