Redis usage Summary

By default, apsaradb for Redis stores data snapshots in the binary file on the disk. The file name is dump. rdb. You can configure the Redis persistence policy. For example, if the data set has been updated more than M times every N seconds, the data is written to the disk. Alternatively, you can manually call the SAVE or BGSAVE command. Example: it is required that every 60 seconds there are more than 10

By default, apsaradb for Redis stores data snapshots in the binary file on the disk. The file name is dump. rdb. You can configure the Redis persistence policy. For example, if the data set has been updated more than M times every N seconds, the data is written to the disk. Alternatively, you can manually call the SAVE or BGSAVE command. Example: it is required that every 60 seconds there are more than 10

Data Persistence Snapshot

By default, Redis stores data snapshots in the binary file on the disk, with the file name "dump. rdb. You can configure the Redis persistence policy. For example, if the data set has been updated more than M times every N seconds, the data is written to the disk. Alternatively, you can manually call the SAVE or BGSAVE command.
Example: If more than 1000 records are updated every 60 seconds, data is automatically written to the disk.

SAVE 60 1000

This policy is called a snapshot.

Working Principle

• Redis forks.
• The child process starts to write data to the temporary RDB file.
• When the sub-process completes writing the RDB file, replace the old file with the new file.

This method enables Redis to use the copy-on-write technology.

Append-only file

The Snapshot mode is not very robust. When the system is stopped or Redis is accidentally killed, the data written to Redis will be lost. This may not be a big problem for some applications, but Redis is not a proper choice for applications that require high reliability.
Append-only file mode is another option.
You can enable the AOF mode in the configuration file:

appendonly yes

Every time Redis receives a modification request (SET), it will write the data to the end of AOF. When Redis is restarted, Redis will play back the content in AOF.

LOG Rewriting

AOF files will become larger with write operations. So Redis supports an interesting feature: Redis can rebuild AOF in the background without interrupting front-end services. When the command BGREWRITEAOF is executed, Redis will write the minimum command sequence with the re-built data in the memory. If you use AOF, you should always run BGREWRITEAOF.

How much persistence can AOF be achieved?

You can configure how long Redis will fsync data to the disk. There are three options:

• Execute fsync every time there is an update command. This method is very slow but safe.
• Execute fsync every second. This method is fast enough, but data may be lost for one second.
• It never executes fsync and has operating system control. This method is faster and safer.

The recommended (default) policy is to execute fsync every second.

What should I do when the AOF file is damaged?

Redis may crash when writing AOF, and damaged files cannot be used by Reids. To solve this problem, follow these steps:

• Back up your AOF File
• Use redis-check-aof to repair your original file

$ redis-check-aof --fix 
 

• Use diff-u to check the differences between the two files (optional)
• Restart Redis with the repaired File

Working mechanism

The same copy-on-write mechanism is used in log rewriting and snapshot modes.

• Redis forks
• The child process starts to write a new AOF file to a temporary file.
• The parent process saves the new update commands in the memory (and writes these updates to the old AOF file)
• When the child process completes writing a file, the parent process gets a signal and writes the update to the AOF File Created by the child process.
• Redis automatically renames the AOF file and uses the new AOF file.

Source: http://www.imsiren.com/archives/955