Data eviction
Data eviction policies control what happens when new data exceeds the memory limits of a database. Here, you'll learn the available policies and how to change which one is used for a database.
| Redis Cloud |
|---|
The data eviction policy of a database controls what happens when new data exceeds the memory size of a database. Typically, such situations require evicting (or deleting) data previously added to the database.
You can edit database details to change the Data eviction policy setting at the database level.
Available policies
For each database, you can choose from these data eviction policies:
| Available policies | Description |
|---|---|
| allkeys-lru | Keeps most recently used keys; removes least recently used (LRU) keys |
| allkeys-lfu | Keeps frequently used keys; removes least frequently used (LFU) keys |
| allkeys-random | Randomly removes keys |
| volatile-lru | Removes least recently used keys with expire field set to true (Default) |
| volatile-lfu | Removes least frequently used keys with expire field set to true |
| volatile-random | Randomly removes keys with expire field set to true |
| volatile-ttl | Removes keys with expire field set to true and the shortest remaining time-to-live (TTL) value |
| no eviction | New values aren't saved when memory limit is reached When a database uses replication, this applies to the primary database |
Prevent data eviction
To avoid data eviction, make sure your database is large enough to hold required values.
Redis Cloud supports Auto Tiering on Redis Cloud Pro and Redis Flex on Redis Cloud Essentials to prevent data eviction but maintain high performance.
Auto Tiering and Redis Flex can extend your database across RAM and Flash Memory and intelligently manage "hot" (active) data in RAM and "cold" (less active) data in Flash memory (SSD).
Active-Passive replication considerations
When using Active-Passive replication, eviction and expiration only operate on the source (active) database. The target database does not evict or expire data while Active-Passive is enabled.
Do not write to the target database while Active-Passive is enabled. Doing so can cause the following issues:
- The target database cannot rely on eviction or expiration to manage local writes, requiring sufficient memory to handle both replicated data and local writes.
- Local writes create differences between the source and target databases, causing replicated commands to behave differently on each database.
- Inconsistent data can cause replicated commands to fail with errors, which will cause the synchronization process to exit and break replication.
Active-Active replication considerations
The eviction policy mechanism for Active-Active databases kicks in earlier than for standalone databases because it requires propagation to all regions. The eviction policy starts to evict keys when one of the Active-Active instances reaches 80% of its memory limit. If memory usage continues to rise while the keys are being evicted, the rate of eviction will increase to prevent reaching the Out-of-Memory state.