This post is a FAQ for Redis, when users don’t see the data they stored in Redis.
As per the Redis project, Redis is described as an in-memory data structure store. If you are using Redis as an LRU cache, you can see following recommendation from the Redis docs: Using Redis as an LRU cache
Lately, I have received multiple questions about when Redis will lose data. This data loss can be as simple as a few keys disappearing unexpectedly or complete loss of all data in Redis. Below I will talk about the most common causes as well as a few rare cases where this can happen.
Note: These scenarios are common to all Redis hosting environments, including self-hosting Redis in your own data center.
Redis doesn't really lose keys randomly. If the keys have disappeared, then it is likely because of one of the following reasons:
The TTL specified on a key was hit, so the system removed the key. More details around Redis expiration can be found in the documentation for the Expires command. TTL values can be set through operations like SET, PSETEX or EXPIRE.
The INFO command can be used to get stats about how many keys have expired using the expired_keys entry under the STATS section. You can also see the number of keys with a TTL value, as well as the average TTL value, in the KEYSPACE section.
# Stats
expired_keys:46583
# Keyspace
db0:keys=3450,expires=2,avg_ttl=91861015336
See related article with debugging tips
Under memory pressure, the system will evict keys to free up memory. When the used_memory or used_memory_rss values in the INFO command approach the configured maxmemory setting, the system will start evicting keys from memory based on your configured memory policy as described here. You can monitor the number of keys evicted using the same INFO command mentioned previously
# Stats
evicted_keys:13224
See related article with debugging tips
Clients can call the DEL or HDEL commands to explicitly remove keys from Redis. You can track the number of delete operations using the output of the INFO command. If "DEL" or "HDEL" commands have been called, they will listed in the Commandstats section
# Commandstats
cmdstat_del:calls=2,usec=90,usec_per_call=45.00
cmdstat_hdel:calls=1,usec=47,usec_per_call=47.00
See related article with debugging tips
When Redis is configured to replicate data from the master to one or more slaves, the data replication happens asynchronously (e.g. runs in the background). This is explained in detail on the redis.io website. For scenarios where clients are writing to Redis frequently, partial data loss of can occur as a result of the fact that this replication happens in the background. For instance, if the master goes down (due to crash, is patched, etc.) after a client writes key "abc" to the master, but before the background replication has a chance to copy key "abc" to the slave, then that key is lost when the slave takes over as master.
Redis is an in memory data store, so whenever the system is taken down for maintenance, data loss will occur if you don't have a secondary Redis instance configured to replicate data from the primary node. The Azure Redis Basic Tier is an example of such a configuration - there is no secondary node, so whenever the primary node goes down, data is lost.
Clients can call the command FLUSHDB to remove all keys in a single database or they can call FLUSHALL to remove all keys from all databases. I have seen several cases where a customer didn't know they had an obscure code path in their app that would call one of these FLUSH commands and they are surprised when suddenly data disappears. You can get a feel for whether or not you have hit this case by looking at the output of the INFO command. If "flushall" or "flushdb" have been called, they will be listed in the Commandstats section
# Commandstats
cmdstat_flushall:calls=2,usec=112,usec_per_call=56.00
cmdstat_flushdb:calls=1,usec=110,usec_per_call=52.00
Even if you have a multi-node (master/slave) configuration with replication enabled, there is always the possibility that an infrastructure failure (for instance, complete datacenter power outage) causes both nodes to go down at the same time. In such cases, all data will be lost since Redis is an in-memory data store. This type of failure is typically very rare, but Redis users need to be aware that this is a possiblity, even if a remote one.
Consider using Redis Persistence to improve resiliency against these infrastructure failures.