Mastering Redis: Persistence, Replication, and Sentinel for High Availability

Introduction

Redis is a high‑performance key‑value cache that also supports complex data structures such as lists, sets, and sorted sets, and provides persistence capabilities. It can be viewed in three ways: as a key‑value store, an in‑memory cache, and a data‑structure server.

Advantages of Redis

Rich operations on hashes, lists, sets, and sorted sets.

Built‑in replication and clustering.

In‑place updates without service interruption.

Persistence options: RDB and AOF.

Redis Persistence Overview

Redis offers two persistence methods: RDB (snapshot) and AOF (append‑only file). Both can be used together, but BGSAVE and BGWRITEAOF do not run simultaneously. On startup, Redis prefers AOF for data recovery. Persistence aids recovery but does not replace regular backups.

RDB

RDB creates snapshots at configured intervals by forking a child process that copies memory pages (copy‑on‑write) and writes the data to a temporary file. The main process continues serving clients. The main drawback is that only the state at the snapshot time is saved; any changes after the snapshot are lost on restart.

Configuration parameters can be inspected in /etc/redis.conf.

AOF

The main process forks a child that rewrites the in‑memory dataset to a temporary file, while the parent continues handling client requests and appends new write commands to the AOF buffer. After the child finishes, it replaces the old AOF file.

AOF works like MySQL's binary log: every command that modifies data is appended to a log file, which can be replayed on restart. Drawbacks include larger file size and slower recovery, as all commands must be re‑executed, and a potential performance impact on read/write operations.

AOF writes are append‑only, so power loss or crashes do not corrupt existing data.

Redis Persistence I/O and Performance Issues

Heavy memory usage can cause instability before physical RAM is fully exhausted. This is not due to copy‑on‑write alone; the real issue is Buffer I/O. Redis writes persistence files through the OS page cache, duplicating data already held in memory. When the page cache grows large, the kernel may start swapping, leading to crashes. A rule of thumb: if Redis memory usage exceeds 60% of total RAM, risk increases.

Redis Master‑Slave Replication

Redis supports asynchronous master‑slave replication with multiple slaves and chain replication. A slave requests a snapshot from the master, which forks a child process to create the snapshot file, sends it to the slave, and the slave loads it to rebuild its dataset.

Key Features of Replication

Asynchronous replication with periodic progress reports.

Multiple slaves per master; slaves can have their own slaves (cascading).

Replication does not block the master.

Provides data redundancy and read‑scaling.

Slaves are read‑only by default; Sentinel can provide HA by promoting a slave when the master fails.

Configuration example: edit /etc/redis.conf, set bind to the local IP, and restart.

Redis Sentinel for High Availability

Sentinel monitors Redis instances, sends notifications, and performs automatic failover. If the master becomes unavailable, Sentinel promotes a slave to master and reconfigures the remaining slaves. Sentinel distinguishes two failure states: S_DOWN (no ping response) and O_DOWN (enough Sentinels agree the master is down).

Sentinel Architecture

Practical setup: run multiple Redis nodes on a single server, configure sentinel.conf to monitor the master, and test failover by killing the master process (e.g., port 6381) and observing promotion of another node (e.g., port 6380).

Conclusion

Redis persistence via RDB provides snapshot‑based recovery but may lose recent data on crash, while AOF offers append‑only logging that survives power loss but can be slower and larger. Using both together improves data safety, but backups remain essential. Replication adds redundancy and read scaling, and Sentinel delivers automated failover for high availability.