Optimizing Redis Master‑Slave Performance in Cloud Environments

Redis is a high‑performance in‑memory database. This article focuses on issues that arise in Redis master‑slave mode, especially when deployed in cloud environments, and offers practical tuning methods.

Master Node Optimizations

To reduce I/O on the master, disable AOF and the periodic save snapshots:

Disable AOF: config set appendonly no Disable automatic save triggers: config set save "" Disabling save prevents frequent bgsave operations that can cause noticeable performance drops, though occasional full sync may still occur when a slave reconnects after a long disconnection.

Key Count Inconsistency After Replication

When many keys with expiration exist, the master’s key eviction process may not propagate deletions to slaves, leading to mismatched key counts. The default eviction loop processes only 20 keys per iteration ( #define ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 20 in redis.h). You can mitigate this by increasing the server’s cron frequency via the hz setting in redis.conf.

Client Output Buffer Limits Causing Frequent Full Sync

Redis maintains a send buffer for each client connection. If the buffer fills, Redis disconnects the client to protect itself, which can trigger frequent full synchronizations in high‑write scenarios. Adjust the buffer limits according to actual write volume and network conditions:

config set client-output-buffer-limit "slave 4295000768 4295000768 0"

Here slave refers to replica connections; normal for regular clients and pubsub for publish/subscribe clients.

Replication Backlog Size

The replication backlog stores recent write commands for replicas. Its default size is 1 MiB. If a replica reconnects within the backlog window, a partial sync occurs; otherwise, a full sync is required. Adjust the size as needed:

config set repl-backlog-size <em>desired_size</em>

Node Liveness Detection

High‑availability setups rely on fast node liveness checks. Redis combines process detection with service pinging. A long‑running command (e.g., a query that blocks for minutes) can cause ping timeouts and false failovers. Mitigate this by increasing ping timeout and the number of ping attempts, balancing rapid failure detection with tolerance for occasional heavy commands.

Slave Node Configuration

Replicas ensure data safety and can be promoted to master after a failure. When operating as a replica, enable both RDB and AOF persistence and regularly back up RDB files to a cold‑storage location. Upon promotion, restore the master‑like configuration immediately.