How to Optimize Redis Server Config, Eviction Policies, and Sentinel Failover

Server Configuration

Redis 2.8.19 server with Jedis 2.6.0 client is used. The maxmemory-policy default allkeys-lru caused key eviction after a large HGETALL blew memory, wiping important data. Switching to noeviction prevents eviction but should only be used when Redis stores core data rather than a cache.

Because Redis allocates an output buffer per client request, an unbounded client-output-buffer-limit normal 0 0 0 can let a single heavy query consume massive memory. The article limits it to client-output-buffer-limit normal 10mb 5mb 10 (or lower) to avoid runaway memory usage.

Dangerous commands can be disabled via rename-command:

rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command SHUTDOWN ""
rename-command KEYS ""
rename-command MONITOR ""

Master‑Slave Switch (Sentinel)

Sentinel monitors master health and promotes a slave when needed. The article describes a real incident where two slaves remained slaves after a restart because static slaveof lines in configuration prevented automatic promotion.

Common failure reasons:

More than half of the sentinels are down, preventing quorum.

Sentinels vote for themselves, leaving no leader.

Slaves not meeting selection criteria (state, ping latency, info_refresh, down‑after‑milliseconds, priority).

Emergency actions include forcing a failover with a surviving sentinel, manually promoting a slave with slaveof no one, or rebuilding the topology.

Sentinel deployment recommendations:

Deploy an odd number of sentinels (minimum 3) on separate physical machines.

Use

sentinel monitor master <ip> <port> <quorum>

with quorum > half of sentinels.

Set sentinel failover-timeout master 900000 (15 min) or lower to reduce wait time.

Persistence

Redis offers RDB snapshots and AOF logs. RDB bgsave forks a process; on large datasets (e.g., 35 GB) it can block for >200 ms and consume significant CPU and memory. The article recommends keeping memory under 20 GB for RDB.

AOF provides near‑zero data loss but grows quickly. The fsync policy should be everysec to balance durability and performance. During bgrewriteaof CPU can reach 100 % and block client requests.

Choosing a persistence strategy depends on tolerance for data loss:

If full data loss is acceptable, disable persistence on both master and slave.

If partial loss is acceptable, enable RDB on master or slave depending on dataset size.

If no loss is acceptable, enable AOF on both sides with everysec and schedule bgrewriteaof during idle periods.

In production the team disables persistence on the master, enables RDB on the slave, and backs up the slave RDB every five minutes, retaining one hour of backups for manual recovery.