Traditionally we are used to storing data in an RDBMS like MySQL, and avoid using in-memory solutions such as Redis, to have a confidence of no data loss. Sometimes I find that we are so stubborn with MySQL that ending up with a complicated design, and I've even seen a solution that stores data in MySQL and then using Redis as a cache for it to improve read performance in the meanwhile. And to make the data in the cache as consistent as possible with the data in MySQL, it introduces other mechanisms, but the result is still not 100% consistent.
So I wonder, is it safe to use Redis as a data store directly? Since if that's OK, we can have a clean solution without using MySQL for, at least, in the above scenario.
Redis has two data persistence solutions: the RDB persistence and AOF persistence. The RDB persistence is suitable for making complete point-in-time backups every a few minutes, which can be configured via the save directive. And the AOF persistence is finer-grained, as it logs every command that it executes, and there are three options for how frequent it flushes ([[https://man7.org/linux/man-pages/man2/fsync.2.html][fsync]]'ing in the syscall level) the AOF file to the disk (the appendfsync option):
- always:
fsyncevery time a new command is appended to the AOF. - everysec:
fsyncevery second. - no: Never
fsync, it's up to the OS when to fsync the file.
So the answer is yes, for a situation that Redis is more suitable to organize the data in a NoSQL style. Use always for appendfsync if we can't tolerate any data loss, and use everysec if the data is not that important, and we can endure a second of data loss, at most.
As a comparison, MySQL has a similar mechanism called binary log (binlog) to log its SQL statements, and there is also a configuration directive, sync_binlog, to control how often it fsync's:
- 0, never
fsyncexplicitly - 1,
fsyncevery statement - N (N>1),
fsyncevery N statements
So it's OK to use Redis as a data store with the AOF persistence enabled, it can be as safe as MySQL in theory.