3 ms·

Sort of. Given a continuum of reliability needs, options for variably controlling the window of data loss are welcome. The bottom line is solid-state componen

• antirez 17y ago
  Well there are many ways to add durability to an in-memory DB. For instance Redis 1.1 is supporting three of this ways with different degrees of safety VS performances. 1 - snapshotting) This uses the idea that after a fork() the OS uses copy-on-write semantics. So Redis forks() and dumps a very compact snapshot of the data in RAM on disk. This snapshot is also used in master-slave replication for the initial synchronization. You can configure different save-points, for instance save when there are at least 100 changes and 60 seconds elapsed, and so forth. 2 - append only journal) In this mode Redis just append every command that modified the DB into a file, in order to later reload the log to rebuild the status of the DB. This is much more durable. This days I'm coding a command that is able to rebuild the log in background in order to avoid to end with a huge log. The rebuilding process is fully non-blocking as it uses the same trick of the background snapshotting, that is, copy-on-write of fork. So basically Redis forks and starts to rebuild the append-only log on a different file. The parent process continues to log to the old file and accumulates all the new differences in RAM. When the child finished the rebuild, the parent adds all the new logs at the end of the file and atomically rename(2) the new log to the old one. 3 - master-slave replication.
  • jeremyw 17y ago
    That's exactly the continuum I'm referring to.