Redis delivers high-speed read/write performance but can face heavy read loads under production traffic. To distribute this load, Redis supports master-slave replication, enabling one-to-many or cascading topologies. Replication operates via full synchronization (during initialization) or incremental synchronization (for ongoing updates).

Benefits of Master-Slave Architecture

• Data Redundancy: Acts as a hot backup beyond disk persistence.
• Failover Recovery: Slaves can serve requests if the master fails.
• Load Balancing: Write operations route to the master; reads distribute across slaves — ideal for read-heavy workloads.
• Scalable Reads: Add or remove slaves dynamically to adjust read capacity.
• HA Foundation: Essential groundwork for Sentinel and Cluster deployments.

Replication Workflow

1. Slave connects to master using REPLICAOF <master-ip> <port>.
2. Master triggers BGSAVE, generates an RDB snapshot, and buffers new writes.
3. Snapshot is sent to slave, which flushes old data and loads the snapshot.
4. Buffered write commands are streamed to slave for consistency.
5. Post-sync, all new master writes propagate instantly to slaves.
6. Use INFO REPLICATION to inspect status — survives node restarts.
7. On reconnect, slave sends PSYNC; master responds with only missing ops.

Full vs Incremental Sync

Full Sync occurs during slave initialization:

1. Slave requests sync via SYNC.
2. Master creates RDB + logs subsequent writes.
3. Sends RDB to slave, then buffered writes.
4. Slave applies both to achieve parity.

Incremental Sync maintains sync post-initialization:

1. Slave reconnects and issues PSYNC.
2. Master streams only missed commands since last offset.

Redis always attempts incremental sync first. If impossible (e.g., after slave restart), it falls back to full sync. Caution: mlutiple slaves restarting simultaneously may overwhelm the master with concurrent full syncs.

Should Master Enable Persistence?

Yes, strongly recommended in production. Without persistence, a master restart with empty dataset forces slaves to discard their data during resync. Example: Master has 10k keys; Slave has 9k synced. If master restarts without persistence, it syncs 0 keys → slave deletes 9k keys. Enabling RDB/AOF on master prevents catastrophic data loss.

Deployment Steps

Host Planning

Environment Setup

wget http://download.redis.io/releases/redis-6.2.6.tar.gz
yum -y install gcc make
systemctl disable --now firewalld NetworkManager
setenforce 0
sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config

Compile & Install

tar xf redis-6.2.6.tar.gz
mv redis-6.2.6 /usr/local/redis
cd /usr/local/redis && make

Configure Environment

echo 'export PATH=/usr/local/redis/src:$PATH' >> /etc/profile
source /etc/profile
mkdir -p /data/6379

Configuration Files

Master (10.0.0.31)

cat > /data/6379/redis.conf <<eof appendfsync="" appendonly="" bind="" daemonize="" dir="" eof="" everysec="" logfile="" masterauth="" pidfile="" port="" requirepass="" save="" secretpass123="" yes=""></eof>

Slaves (10.0.0.32, 10.0.0.33) — same except bind IP.

Launch & Manage

redis-server /data/6379/redis.conf

Systemd Service

cat > /usr/lib/systemd/system/redis.service <<eof after="network.target" daemon-reload="" description="Redis" enable="" eof="" execstart="/usr/local/redis/src/redis-server" execstop="/usr/local/redis/src/redis-cli" redis="" secretpass123="" server="" shutdown="" systemctl="" systemd="" type="notify" user="root" wantedby="multi-user.target"></eof>

Kernel Tuning

echo 511 > /proc/sys/net/core/somaxconn
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo "* soft nofile 65535" >> /etc/security/limits.conf
echo "* hard nofile 65535" >> /etc/security/limits.conf

Enable Replication

Configure Slaves

# On 10.0.0.32
redis-cli -h 10.0.0.32 -p 6379 -a SecretPass123 REPLICAOF 10.0.0.31 6379

# On 10.0.0.33
redis-cli -h 10.0.0.33 -p 6379 -a SecretPass123 REPLICAOF 10.0.0.31 6379

Verify Replication

Master Status

redis-cli -p 6379 -a SecretPass123 INFO REPLICATION
# Output shows 2 connected slaves

Test Data Sync

# On master
SET user.name "Alice"
SET user.age "25"

# On slaves
GET user.name  # Returns "Alice"
GET user.age   # Returns "25"

Manual Failover

Promote Slave to Master

# Stop original master
systemctl stop redis

# On slave (10.0.0.32)
redis-cli -a SecretPass123 REPLICAOF NO ONE
SET emergency.flag "active"  # Now writable

Restore Original Master

1. Copy dump.rdb and appendonly.aof from promoted slave to original master’s /data/6379/.
2. Restart original master: systemctl start redis.
3. Demote temporary master back to slave: REPLICAOF 10.0.0.31 6379.

Break Replication

# On any slave
redis-cli -a SecretPass123 REPLICAOF NO ONE