What happened to my data in Redis?
---------------
This post is a FAQ for Redis, when users don’t see the data they stored in Redis.

As per the [Redis project](http://redis.io), **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](http://redis.io/topics/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.**

###*Some* of my keys have disappeared - why?
Redis doesn't really lose keys randomly.  If the keys have disappeared, then it is likely because of one of the following reasons: 

####***Expiration:***

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](http://redis.io/commands/expire).  TTL values can be set through operations like [SET](http://redis.io/commands/set), [PSETEX](http://redis.io/commands/psetex) or [EXPIRE](http://redis.io/commands/expire).  

The [INFO command](http://redis.io/commands/info) 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    

####***Eviction:***

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](http://redis.io/commands/info) approach the configured *maxmemory* setting, the system will start evicting keys from memory based on your configured memory policy as described [here](http://redis.io/topics/lru-cache).  You can monitor the number of keys evicted using the same INFO command mentioned previously

    # Stats
    evicted_keys:13224

####***Async Replication:***

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](http://redis.io/topics/replication).  For scenarios where clients are writing to Redis frequently, partial data loss of can occur as a result of the fact that this synchronization 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 synchronization has a chance to replicate key "abc" to the slave, then that key is lost when the slave takes over as master.

###*Most/All* of my keys are gone - what happened?

####***FLUSH***

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 suddently 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](http://redis.io/commands/info).  If "flushall" or "flushdb" have been called, they will 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

####Multi-node failure

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

Consider using [Redis Persistence](http://redis.io/topics/persistence) to improve resiliency against these infrastructure failures.