pub-technology · March 28, 2018 01:58 · Oct 23, 2017 · May 2, 2017 · Mar 21, 2017 · Dec 5, 2016
diff --git a/WhatHappenedToMyDataInRedis.md b/WhatHappenedToMyDataInRedis.md
@@ -55,7 +55,7 @@ Redis is an *in memory* data store, so whenever the system is taken down for mai
 
 ### ***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 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](http://redis.io/commands/info).  If "flushall" or "flushdb" have been called, they will listed in the *Commandstats* section
+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](http://redis.io/commands/info).  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

diff --git a/WhatHappenedToMyDataInRedis.md b/WhatHappenedToMyDataInRedis.md
@@ -50,7 +50,7 @@ When Redis is configured to replicate data from the master to one or more slaves
 
 ## *Most or All* of my keys are gone - what happened?
 
-### ***No Replica Node Configured***
+### ***Single-node configuration***
 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.  
 
 ### ***FLUSH***

diff --git a/WhatHappenedToMyDataInRedis.md b/WhatHappenedToMyDataInRedis.md
@@ -1,4 +1,4 @@
-#What happened to my data in Redis?
+# 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.
 
@@ -8,10 +8,10 @@ Lately, I have received multiple questions about when Redis will lose data. This
 
 **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?
+## *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:***
+### ***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).  
 
@@ -25,7 +25,7 @@ The [INFO command](http://redis.io/commands/info) can be used to get stats about
 
 See [related article with debugging tips](https://gist.github.com/JonCole/4a249477142be839b904f7426ccccf82#debugging-redis-keyspace-misses)
 
-###***Eviction:***
+### ***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
 
@@ -34,7 +34,7 @@ Under memory pressure, the system will evict keys to free up memory.  When the *
 
 See [related article with debugging tips](https://gist.github.com/JonCole/4a249477142be839b904f7426ccccf82#debugging-redis-keyspace-misses)
 
-###***Key Deletion***
+### ***Key Deletion***
 
 Clients can call the [DEL](http://redis.io/commands/del) or  [HDEL](http://redis.io/commands/hdel) commands to explicitly remove keys from Redis. You can track the number of delete operations using the output of the [INFO command](http://redis.io/commands/info).  If "DEL" or "HDEL" commands have been called, they will listed in the *Commandstats* section
 
@@ -44,24 +44,24 @@ Clients can call the [DEL](http://redis.io/commands/del) or  [HDEL](http://redis
 
 See [related article with debugging tips](https://gist.github.com/JonCole/4a249477142be839b904f7426ccccf82#debugging-redis-keyspace-misses)
 
-###***Async Replication:***
+### ***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 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.
 
-##*Most or All* of my keys are gone - what happened?
+## *Most or All* of my keys are gone - what happened?
 
-###***No Replica Node Configured***
+### ***No Replica Node Configured***
 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.  
 
-###***FLUSH***
+### ***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 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](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***
+### ***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.  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.
 

diff --git a/WhatHappenedToMyDataInRedis.md b/WhatHappenedToMyDataInRedis.md
@@ -50,9 +50,12 @@ When Redis is configured to replicate data from the master to one or more slaves
 
 ##*Most or All* of my keys are gone - what happened?
 
+###***No Replica Node Configured***
+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.  
+
 ###***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
+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](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

diff --git a/WhatHappenedToMyDataInRedis.md b/WhatHappenedToMyDataInRedis.md
@@ -23,7 +23,7 @@ The [INFO command](http://redis.io/commands/info) can be used to get stats about
     # Keyspace 
     db0:keys=3450,expires=2,avg_ttl=91861015336    
 
-See [related article with debugging tips](https://gist.github.com/JonCole/4a249477142be839b904f7426ccccf82#for-cases-1-2-and-3-key-expired-was-deleted-or-evicted)
+See [related article with debugging tips](https://gist.github.com/JonCole/4a249477142be839b904f7426ccccf82#debugging-redis-keyspace-misses)
 
 ###***Eviction:***
 
@@ -32,7 +32,7 @@ Under memory pressure, the system will evict keys to free up memory.  When the *
     # Stats
     evicted_keys:13224
 
-See [related article with debugging tips](https://gist.github.com/JonCole/4a249477142be839b904f7426ccccf82#for-cases-1-2-and-3-key-expired-was-deleted-or-evicted)
+See [related article with debugging tips](https://gist.github.com/JonCole/4a249477142be839b904f7426ccccf82#debugging-redis-keyspace-misses)
 
 ###***Key Deletion***
 
@@ -42,7 +42,7 @@ Clients can call the [DEL](http://redis.io/commands/del) or  [HDEL](http://redis
     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](https://gist.github.com/JonCole/4a249477142be839b904f7426ccccf82#for-cases-1-2-and-3-key-expired-was-deleted-or-evicted)
+See [related article with debugging tips](https://gist.github.com/JonCole/4a249477142be839b904f7426ccccf82#debugging-redis-keyspace-misses)
 
 ###***Async Replication:***
 

diff --git a/WhatHappenedToMyDataInRedis.md b/WhatHappenedToMyDataInRedis.md
@@ -6,8 +6,6 @@ As per the [Redis project](http://redis.io), **Redis is described as an in-memor
 
 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. 
 
-For more information about how to debug these scenarios, see [these debugging tips](https://gist.github.com/JonCole/4a249477142be839b904f7426ccccf82#debugging-redis-keyspace-misses).
-
 **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?

diff --git a/WhatHappenedToMyDataInRedis.md b/WhatHappenedToMyDataInRedis.md
@@ -6,6 +6,8 @@ As per the [Redis project](http://redis.io), **Redis is described as an in-memor
 
 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. 
 
+For more information about how to debug these scenarios, see [these debugging tips](https://gist.github.com/JonCole/4a249477142be839b904f7426ccccf82#debugging-redis-keyspace-misses).
+
 **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?

diff --git a/WhatHappenedToMyDataInRedis.md b/WhatHappenedToMyDataInRedis.md
@@ -23,13 +23,17 @@ The [INFO command](http://redis.io/commands/info) can be used to get stats about
     # Keyspace 
     db0:keys=3450,expires=2,avg_ttl=91861015336    
 
+See [related article with debugging tips](https://gist.github.com/JonCole/4a249477142be839b904f7426ccccf82#for-cases-1-2-and-3-key-expired-was-deleted-or-evicted)
+
 ###***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
 
+See [related article with debugging tips](https://gist.github.com/JonCole/4a249477142be839b904f7426ccccf82#for-cases-1-2-and-3-key-expired-was-deleted-or-evicted)
+
 ###***Key Deletion***
 
 Clients can call the [DEL](http://redis.io/commands/del) or  [HDEL](http://redis.io/commands/hdel) commands to explicitly remove keys from Redis. You can track the number of delete operations using the output of the [INFO command](http://redis.io/commands/info).  If "DEL" or "HDEL" commands have been called, they will listed in the *Commandstats* section
@@ -38,6 +42,8 @@ Clients can call the [DEL](http://redis.io/commands/del) or  [HDEL](http://redis
     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](https://gist.github.com/JonCole/4a249477142be839b904f7426ccccf82#for-cases-1-2-and-3-key-expired-was-deleted-or-evicted)
+
 ###***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 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.

diff --git a/WhatHappenedToMyDataInRedis.md b/WhatHappenedToMyDataInRedis.md
@@ -1,5 +1,5 @@
-What happened to my data in Redis?
----------------
+#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)
@@ -8,10 +8,10 @@ Lately, I have received multiple questions about when Redis will lose data. This
 
 **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?
+##*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:***
+###***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).  
 
@@ -23,37 +23,37 @@ The [INFO command](http://redis.io/commands/info) can be used to get stats about
     # Keyspace 
     db0:keys=3450,expires=2,avg_ttl=91861015336    
 
-####***Eviction:***
+###***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
 
-####***Key Deletion***
+###***Key Deletion***
 
 Clients can call the [DEL](http://redis.io/commands/del) or  [HDEL](http://redis.io/commands/hdel) commands to explicitly remove keys from Redis. You can track the number of delete operations using the output of the [INFO command](http://redis.io/commands/info).  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
 
-####***Async Replication:***
+###***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 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.
 
-###*Most or All* of my keys are gone - what happened?
+##*Most or All* of my keys are gone - what happened?
 
-####***FLUSH***
+###***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
+###***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.  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](http://redis.io/topics/persistence) to improve resiliency against these infrastructure failures.
+Consider using [Redis Persistence](http://redis.io/topics/persistence) to improve resiliency against these infrastructure failures.
diff --git a/WhatHappenedToMyDataInRedis.md b/WhatHappenedToMyDataInRedis.md
@@ -30,6 +30,14 @@ Under memory pressure, the system will evict keys to free up memory.  When the *
     # Stats
     evicted_keys:13224
 
+####***Key Deletion***
+
+Clients can call the [DEL](http://redis.io/commands/del) or  [HDEL](http://redis.io/commands/hdel) commands to explicitly remove keys from Redis. You can track the number of delete operations using the output of the [INFO command](http://redis.io/commands/info).  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
+
 ####***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 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.

diff --git a/WhatHappenedToMyDataInRedis.md b/WhatHappenedToMyDataInRedis.md
@@ -34,7 +34,7 @@ Under memory pressure, the system will evict keys to free up memory.  When the *
 
 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 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.
 
-###*Most/All* of my keys are gone - what happened?
+###*Most or All* of my keys are gone - what happened?
 
 ####***FLUSH***
 
@@ -46,6 +46,6 @@ Clients can call the command [FLUSHDB]() to remove *all keys* in a *single datab
 
 ####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
+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](http://redis.io/topics/persistence) to improve resiliency against these infrastructure failures.
diff --git a/WhatHappenedToMyDataInRedis.md b/WhatHappenedToMyDataInRedis.md
@@ -32,7 +32,7 @@ Under memory pressure, the system will evict keys to free up memory.  When the *
 
 ####***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.
+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 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.
 
 ###*Most/All* of my keys are gone - what happened?
 

diff --git a/WhatHappenedToMyDataInRedis.md b/WhatHappenedToMyDataInRedis.md
@@ -15,7 +15,7 @@ Redis doesn't really lose keys randomly.  If the keys have disappeared, then it
 
 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 and the number of keys with a TTL value, as well as the average TTL value, in the *KEYSPACE* section.
+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

diff --git a/WhatHappenedToMyDataInRedis.md b/WhatHappenedToMyDataInRedis.md
@@ -38,7 +38,7 @@ When Redis is configured to replicate data from the master to one or more slaves
 
 ####***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 one 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
+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

diff --git a/WhatHappenedToMyDataInRedis.md b/WhatHappenedToMyDataInRedis.md
@@ -0,0 +1,51 @@
+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 and 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 one 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.