Does Redis persist data?

Question

I understand that Redis serves all data from memory, but does it persist as well across server reboot so that when the server reboots it reads into memory all the data from disk. Or is it always a blank store which is only to store data while apps are running with no persistence?

Answer 1

I suggest you read about this on http://redis.io/topics/persistence . Basically you lose the guaranteed persistence when you increase performance by using only in-memory storing. Imagine a scenario where you INSERT into memory, but before it gets persisted to disk lose power. There will be data loss.

Redis supports so-called "snapshots". This means that it will do a complete copy of whats in memory at some points in time (e.g. every full hour). When you lose power between two snapshots, you will lose the data from the time between the last snapshot and the crash (doesn't have to be a power outage..). Redis trades data safety versus performance, like most NoSQL-DBs do.

Most NoSQL-databases follow a concept of replication among multiple nodes to minimize this risk. Redis is considered more a speedy cache instead of a database that guarantees data consistency. Therefore its use cases typically differ from those of real databases: You can, for example, store sessions, performance counters or whatever in it with unmatched performance and no real loss in case of a crash. But processing orders/purchase histories and so on is considered a job for traditional databases.

Answer 2

Redis server saves all its data to HDD from time to time, thus providing some level of persistence.

It saves data in one of the following cases:

• automatically from time to time
• when you manually call BGSAVE command
• when redis is shutting down

But data in redis is not really persistent, because:

• crash of redis process means losing all changes since last save
• BGSAVE operation can only be performed if you have enough free RAM (the amount of extra RAM is equal to the size of redis DB)

N.B.: BGSAVE RAM requirement is a real problem, because redis continues to work up until there is no more RAM to run in, but it stops saving data to HDD much earlier (at approx. 50% of RAM).

For more information see Redis Persistence.

Answer 3

It is a matter of configuration. You can have none, partial or full persistence of your data on Redis. The best decision will be driven by the project's technical and business needs.

According to the Redis documentation about persistence you can set up your instance to save data into disk from time to time or on each query, in a nutshell. They provide two strategies/methods AOF and RDB (read the documentation to see details about then), you can use each one alone or together.

If you want a "SQL like persistence", they have said:

The general indication is that you should use both persistence methods if you want a degree of data safety comparable to what PostgreSQL can provide you.

Answer 4

The answer is generally yes, however a fuller answer really depends on what type of data you're trying to store. In general, the more complete short answer is:

• Redis isn't the best fit for persistent storage as it's mainly performance focused
• Redis is really more suitable for reliable in-memory storage/cacheing of current state data, particularly for allowing scalability by providing a central source for data used across multiple clients/servers

Having said this, by default Redis will persist data snapshots at a periodic interval (apparently this is every 1 minute, but I haven't verified this - this is described by the article below, which is a good basic intro):

http://qnimate.com/redis-permanent-storage/

---

TL;DR

From the official docs:

• RDB persistence [the default] performs point-in-time snapshots of your dataset at specified intervals.
• AOF persistence [needs to be explicitly configured] logs every write operation received by the server, that will be played again at server startup, reconstructing the original dataset.

Redis must be explicitly configured for AOF persistence, if this is required, and this will result in a performance penalty as well as growing logs. It may suffice for relatively reliable persistence of a limited amount of data flow.

Answer 5

You can choose no persistence at all.Better performance but all the data lose when Redis shutting down.

Redis has two persistence mechanisms: RDB and AOF.RDB uses a scheduler global snapshooting and AOF writes update to an apappend-only log file similar to MySql.

You can use one of them or both.When Redis reboots,it constructes data from reading the RDB file or AOF file.

Answer 6

Many Not well-informed and relatively new users think that Redis is a cache only and NOT an ideal choice for Reliable Persistence. The reality is that the lines between DB, Cache (and many more types) are blurred nowadays.

It's all configurable and as users/engineers we have choices to configure it as a cache, as a DB (and even as a hybrid).

Each choice comes with benefits and costs. And this is NOT an exception for Redis but all well-known Distributed systems provide options to configure different aspects (Persistence, Availability, Consistency, etc). So, if you configure Redis in default mode hoping that it will magically give you highly reliable persistence then it's team/engineer fault (and NOT that of Redis).

I have discussed these aspects in more detail on my blog here.

Also, here is a link from Redis itself.

Answer 7

All the answers in this thread are talking about the possibility of redis to persist the data: https://redis.io/topics/persistence (Using AOF + after every write (change)).

It's a great link to get you started, but it is defenently not showing you the full picture.

---

Can/Should You Really Persist Unrecoverable Data/State On Redis?

Redis docs does not talk about:

1. Which redis providers support this (AOF + after every write) option:

• Almost none of them - redis labs on the cloud does NOT provide this option. You may need to buy the on-premise version of redis-labs to support it. As not all companies are willing to go on-premise, then they will have a problem.
• Other Redis Providers does not specify if they support this option at all. AWS Cache, Aivan,...
• AOF + after every write - This option is slow. you will have to test it your self on your production hardware to see if it fits your requirements.
• Redis enterpice provide this option and from this link: https://redislabs.com/blog/your-cloud-cant-do-that-0-5m-ops-acid-1msec-latency/ let's see some banchmarks:

1x x1.16xlarge instance on AWS - They could not achieve less than 2ms latency:

where latency was measured from the time the first byte of the request arrived at the cluster until the first byte of the ‘write’ response was sent back to the client

They had additional banchmarking on a much better harddisk (Dell-EMC VMAX) which results < 1ms operation latency (!!) and from 70K ops/sec (write intensive test) to 660K ops/sec (read intensive test). Pretty impresive!!!

But it defenetly required a (very) skilled devops to help you create this infrastructure and maintain it over time.

2. One could (falsy) argue that if you have a cluster of redis nodes (with replicas), now you have full persistency. this is false claim:

• All DBs (sql,non-sql,redis,...) have the same problem - For example, running set x 1 on node1, how much time it takes for this (or any) change to be made in all the other nodes. So additional reads will receive the same output. well, it depends on alot of fuctors and configurations.
• It is a nightmare to deal with inconsistency of a value of a key in multiple nodes (any DB type). You can read more about it from Redis Author (antirez): http://antirez.com/news/66. Here is a short example of the actual ngihtmare of storing a state in redis (+ a solution - WAIT command to know how much other redis nodes received the latest change change):

    def save_payment(payment_id)
        redis.rpush(payment_id,”in progress”) # Return false on exception
        if redis.wait(3,1000) >= 3 then
            redis.rpush(payment_id,”confirmed”) # Return false on exception
            if redis.wait(3,1000) >= 3 then
                return true
            else
                redis.rpush(payment_id,”cancelled”)
                return false
            end
        else
            return false
    end

The above example is not suffeint and has a real problem of knowing in advance how much nodes there actually are (and alive) at every moment.

Other DBs will have the same problem as well. Maybe they have better APIs but the problem still exists.

As far as I know, alot of applications are not even aware of this problem.

All in all, picking more dbs nodes is not a one click configuration. It involves alot more.

---

To conclude this research, what to do depends on:

1. How much devs your team has (so this task won't slow you down)?
2. Do you have a skilled devops?
3. What is the distributed-system skills in your team?
4. Money to buy hardware?
5. Time to invest in the solution?
6. And probably more...