Redis persistence Policy

Redis persistence

Although redis is a memory-based storage system, it supports the persistence of memory data and provides two main persistence policies: RDB snapshot and aof log.

Redis RDB Snapshot

Redis supports the persistence mechanism of saving the snapshot of the current data into a data file, that is, the RDB snapshot. This method is quite understandable, but how does one generate snapshots for a continuously written database? Redis uses the copy on write mechanism of the fork command. When a snapshot is generated, the current process is fork out of a sub-process, and then all the data is recycled in the sub-process to write the data into an RDB file.

We can configure the RDB snapshot generation time using the Save command of redis. For example, you can configure to generate a snapshot when there are 100 writes within 10 minutes, you can also configure to generate a snapshot when there are 1000 writes within one hour, or you can implement multiple rules together. These rules are defined in the redis configuration file. You can also use the redis config set command to set rules during redis running without restarting redis.

The RDB file of redis will not be broken because the write operation is performed in a new process. When a new RDB file is generated, the child process generated by redis first writes the data to a temporary file, and then renames the temporary file to the RDB file through an atomic rename system call. This causes a fault at any time, redis RDB files are always available. At the same time, the redis RDB file is also a part of the internal implementation of redis master-slave synchronization.

Redis aof log

The full name of aof logs is append only file. It can be seen from the name that it is an append log file.

Aof is a file write operation. Its purpose is to write operation logs to the disk. Therefore, it will also encounter five write operations. How high is the security of aof writing. In fact, this can be set. After calling write (2) for aof in redis, when will fsync be called to write it to the disk and controlled through the appendfsync option, the following three appendfsync settings gradually increase the security intensity.

1) appendfsync No

When appendfsync is set to no, redis does not actively call fsync to synchronize the aof log content to the disk, so all of this depends on the operating system debugging. For most Linux operating systems, fsync is performed every 30 seconds to write data in the buffer zone to the disk.

2) appendfsync everysec

When appendfsync is set to everysec, redis performs an fsync call every second by default to write data in the buffer zone to the disk. However, when the fsync call lasts for more than 1 second. Redis will adopt the fsync delay policy and wait a second. That is, perform fsync two seconds later. This fsync will be executed no matter how long it will take. At this time, because the file descriptor will be blocked during fsync, the current write operation will be blocked. The conclusion is that in most cases, redis performs fsync every second. In the worst case, an fsync operation is performed in two seconds. This operation is called group commit in most database systems. It combines the data of multiple write operations and writes logs to the disk at one time.

3) appednfsync always

When appendfsync is set to always, fsync is called for every write operation. Data is the safest. Of course, because fsync is executed every time, its performance will also be affected.

Redis persistence Policy