Common Issues and Best Practices for Redis Master‑Slave Configuration

The article discusses rare but serious problems that arise when Redis master‑slave configurations are inconsistent.

Issue 1: Different maxmemory settings (e.g., master 4 GB, slave 2 GB) can cause data loss during a full synchronization because the slave cannot load the master's RDB file and triggers its eviction policy.

Issue 2: Mismatched data‑structure optimization parameters such as hash-max-ziplist-entries lead to memory inconsistency between master and slave.

Issue 3: Replication performance problems stem from the initial full sync, where the master dumps a large RDB file and streams it to the slave; this operation blocks the single‑threaded master and may cause service interruption, especially when the disk I/O is slow.

The root cause of these problems is often a system I/O bottleneck, where slow disk read/write speeds block fsync() or write() calls.

Issue 4: Redis’s master‑slave replication can introduce a single point of failure. Custom solutions such as proactive replication or using a proxy to replace a failed master are recommended.

Recommendations: • Do not enable persistence (RDB snapshots or AOF) on the master. • If data is critical, enable AOF on a slave with a one‑second sync policy. • Keep master and slave on the same LAN to improve replication speed and stability. • Avoid adding many slaves to a heavily loaded master. • Use a linear chain topology (Master←Slave1←Slave2←Slave3…) to simplify failover; if the master fails, Slave1 can be promoted immediately.