3 ms·

Redis persists to the filesystem pretty regularly by default, and can be configured to do it much more often. For example, the recommended configuration for its

Redis persists to the filesystem pretty regularly by default, and can be configured to do it much more often. For example, the recommended configuration for its AOF persistence mode is to fsync every second, but you can set it to fsync after every command if you don't want to risk losing even a single second of commands. Lots more info here: https://redis.io/topics/persistence https://redis.io/topics/persistence

jjjensen90 7y ago
One second is a significant gap for data loss. Also please be aware that if you use AOF persistence, and need to restore a redis instance from an AOF file, you MUST have at least the same amount of RAM available as the AOF file is in size or you cannot restore, and you can even corrupt the AOF in that instance. I work somewhere that previously (before I started) decided to use redis as a database for many applications and it has caused a lot of pain and the engineering department severely regrets it. I do still recommend it as a great cache/session store, especially if you outsource it to elasticache.
- fpereiro 7y ago
  > One second is a significant gap for data loss. Definitely agree. I would not, for example, create a financial transaction system that is not backed by an ACID database that persists to disk. If you have time/interest, I'd love to know more about the problems encountered by your team when using redis. In my experience, the main problem is scaling it to multiple instances (because RAM grows linearly with use). If the team also encountered other reliability issues, it would be valuable knowledge to me and perhaps others.