tags:

views:

373

answers:

1

By "durable" I mean, the server can crash at any time, and as long as the disk remains in tact, no data is lost (see ACID). Seems like that's what journaling mode is for, but if you enable journaling, doesn't that defeat the purpose of operating on in-memory data? Read operations might not be affected by journaling, but it seems like journaling would kill your write performance.

+7  A: 

No. Redis is not a "durable" datastore, in the sense of the "D" in ACID.

In journaling mode, redis writes to disk as fast as it can, but may fall behind. Any data that has been stored to memory, but not yet journalled would be lost in the event of a crash.

Redis intentionally sacrifices a little durability in return for speed.

...After reading the docs closer, I see that's not strictly true. The "append only file" storage mode can optionally be configured to operate in a durable manner, at the cost of performance.

From the docs:

How durable is the append only file?

Check redis.conf, you can configure how many times Redis will fsync() data on disk. There are three options:

  • Fsync() every time a new command is appended to the append log file. Very very slow, very safe.
  • Fsync() one time every second. Fast enough, and you can lose 1 second of data if there is a disaster.
  • Never fsync(), just put your data in the hands of the Operating System. The faster and unsafer method.

Warning: by default Redis will fsync() after every command! This is because the Redis authors want to ship a default configuration that is the safest pick. But the best compromise for most datasets is to fsync() one time every second.

Frank Farmer
Good to know. Can you provide a link to support what you're saying?
allyourcode