Redis replication enables a distributed data architecture where one node acts as the authoritative primary (master) for all write operations, while one or more replica (slave) nodes handle read requests. This separation improves scalability, fault tolerance, and operational safety.

Core Principles

• Write-only primary: All mutations (SET, DEL, INCR, etc.) must occur on the master.
• Read-only replicas: By default, replicas reject write commands with READONLY error unless explicitly promoted.
• Automatic synchronization: Replicas fetch full dataset snapshots (RDB) on first connection, then apply incremental updates via the replication stream.

Deployment Topologies

Three common patterns:

1. Simple Master-Replica: One master serves multiple replicas (e.g., 1×6379 → 2×6379).
2. Chained Replication: A replica itself becomes a master to downstream replicas — reducing bandwidth pressure on the root master.
3. Failover Promotion: Manual or automated promotion of a replica to master using SLAVEOF NO ONE or Redis Sentinel.

Practical Setup Example

Assume three hosts:

• Primary: 192.168.1.66:6379
• Replica A: 192.168.1.61:6379
• Replica B: 192.168.1.62:6379

On each replica, configure replication dynamically:

192.168.1.61:6379> SLAVEOF 192.168.1.66 6379
OK

If authentication is enabled on the master (e.g., requirepass 123456), add to replica’s config or runtime:

192.168.1.61:6379> CONFIG SET masterauth "123456"
OK

Verify roles with INFO REPLICATION:

• Master shows role:master and lists connected replicas under connected_slaves.
• Replica shows role:slave, master_link_status:up, and current replication offset.

Authentication & Network Considerations

A NOAUTH Authentication required error means the replica lacks credentials to connect. Fix by setting masterauth in redis.conf or via CONFIG SET.

Ensure firewall rules allow inbound traffic on port 6379:

sudo iptables -I INPUT 4 -p tcp --dport 6379 -j ACCEPT

Failover Mechanics

To manually promote Replica A:

192.168.1.61:6379> SLAVEOF NO ONE
OK

It now accepts writes and can serve as a new master. Downstream replicas (e.g., 62) must be reconfigured to follow it:

192.168.1.62:6379> SLAVEOF 192.168.1.61 6379

Automated Failover with Redis Sentinel

Create /etc/redis/sentinel.conf on a monitoring host (e.g., replica node):

port 26379
sentinel monitor mycluster 192.168.1.66 6379 1
sentinel auth-pass mycluster 123456
sentinel down-after-milliseconds mycluster 5000
sentinel failover-timeout mycluster 60000

Start Sentinel:

redis-sentinel /etc/redis/sentinel.conf

Sentinel detects master failure, elects a leader, promotes a replica, and reconfigures remaining nodes — including demoting the recovered master to replica status.

Operaitonal Notes

• Replication lag: There's inherent delay between master write and replica visibility — critical for strongly consistent reads.
• One-time full sync: Every time a replica reconnects after disconnection, it triggers a full resync unless partial sync is possible (via replication backlog).
• ReadOnly enforcement: Replicas default to slave-read-only yes; disable only if intentional write-through logic is implemented at application layer.