In a Redis primary–replica setup where both nodes have `maxmemory` configured, does a replica evict keys on its own when it reaches the limit? Explain what actually causes data to disappear from a replica.

## The rule: primaries decide, replicas obey Redis replication is a stream of write effects. When a primary evicts a key under memory pressure, it does not tell replicas "I am over maxmemory"; it deletes the key locally and propagates an explicit deletion command — `DEL`, or `UNLINK` when lazy-freeing is enabled — into the replication link and the AOF. Replicas execute it as an ordinary replicated write. That design exists to keep replicas byte-identical to the primary. Eviction heuristics are approximate and sampled: if each node independently chose victims, two replicas of the same primary would drop different keys. A read routed to replica A would miss a key that replica B still serves, and a failover would promote a node with an arbitrary subset of the data. Making eviction a single-writer decision at the primary removes that class of divergence entirely. ## `replica-ignore-maxmemory` Since Redis 5.0 the directive `replica-ignore-maxmemory` defaults to `yes` (it was `slave-ignore-maxmemory` before the terminology change). With it enabled, a replica does not perform eviction for replicated data even if its own `used_memory` exceeds its own `maxmemory`. It still honors the limit in one respect: as a *replica*, it is not accepting client writes anyway, so the OOM error path barely applies. The practical implication is that **a replica can legitimately sit above its configured `maxmemory`**. Its footprint is the dataset plus the replication backlog buffer, plus client output buffers for any read traffic it serves, plus the same allocator fragmentation the primary has. So a replica sized exactly like the primary can OOM-kill first. Give replicas at least as much RAM as the primary, and watch `used_memory_rss` rather than trusting the configured cap. Setting `replica-ignore-maxmemory no` re-enables independent eviction. It is almost always a mistake: you trade a memory ceiling for silent divergence. ## Where replicas *do* delete on their own Two cases are worth naming precisely so you do not overstate the rule. **Writable replicas.** With `replica-read-only no`, clients may write directly to a replica. Those locally-written keys are not part of the replicated dataset, and Redis tracks them separately so it can reclaim them without corrupting replication state. This is a niche feature for scratch data; a full resync from the primary wipes such keys, so nothing durable belongs there. **Promotion.** The moment a replica is promoted to primary — by Sentinel, by cluster failover, or by a manual `REPLICAOF NO ONE` — it becomes the node making eviction decisions. Its `maxmemory` and `maxmemory-policy` now govern the whole dataset. If you configured the replica with `noeviction` "because it never evicts anyway", the newly promoted primary will start rejecting writes with OOM errors at exactly the worst moment. **Configure replicas with the same memory settings you want after failover.** ## Expiration is a separate mechanism with the same shape Key expiry follows the same primary-authoritative model: the primary decides a key is expired and propagates an explicit deletion; replicas do not remove expired keys from their own keyspace on their own initiative, though they will hide a logically-expired key from reads. The detailed lazy/active expiry cycle is its own subject — the point relevant here is simply that eviction and expiration are *different* mechanisms that happen to share the propagate-a-DEL design, and neither makes a replica an independent decision-maker. ## Operating checklist - Size replica RAM ≥ primary RAM; replication and output buffers are on top of the dataset. - Leave `replica-ignore-maxmemory` at `yes` unless you have an unusual, well-understood reason. - Give replicas the `maxmemory-policy` you want them to use **after promotion**, and verify it with `CONFIG GET maxmemory-policy` on every node, not just the primary. - Expect `evicted_keys` in `INFO stats` to be ~0 on replicas; evictions show up on the primary. A non-zero counter on a replica means either it was recently a primary or someone disabled the default. - Remember reads served from replicas can see slightly stale data because replication is asynchronous; that is independent of eviction, but it compounds the confusion when someone reports "the key is on one node and not the other" right after a failover.