The advantages of the RDB mechanism and the slight application
of RDB persistence refers to writing an in-memory snapshot of a dataset to disk at a specified time interval. It is also the default persistence method. This method is to write the data in memory to the binary file in the form of a snapshot. The default file name is dump.rdb.
Snapshot persistence can be done automatically through configuration settings. We can configure redis to automatically take snapshots if more than m keys are modified within n seconds. The following is the default snapshot save configuration
save 900 1 #If more than 1 key is modified within 900 seconds, initiate snapshot save save 300 10 #300 seconds, if more than 10 keys are modified, initiate snapshot save save 60 10000
The RDB file saving process
redis calls fork, and now there is a child process and a parent process.
The parent process continues to process client requests, and the child process is responsible for writing the memory content to the temporary file. Due to the copy-on-write mechanism of OS, the parent and child processes will share the same physical page. When the parent process processes the write request, the OS will create a copy of the page to be modified by the parent process instead of writing the shared page. So the data in the address space of the child process is a snapshot of the entire database at the moment of fork.
After the child process writes the snapshot to the temporary file, it replaces the original snapshot file with the temporary file, and then the child process exits.
The client can also use the save or bgsave command to notify redis to do a snapshot persistence. The save operation saves the snapshot in the main thread. Since redis uses a main thread to process all client requests, this method will block all client requests. So it is not recommended to use.
Another point to note is that each snapshot persistence is to completely write the memory data to the disk once, not only the dirty data is incrementally synchronized. If the amount of data is large and there are many write operations, it will inevitably cause a large number of disk IO operations, which may seriously affect performance.
Advantages
Once this method is adopted, your entire Redis database will contain only one file, which is very convenient for backup. For example, you may plan to archive some data every day.
To facilitate backup, we can easily move RDB files one by one to other storage media.
RDB is faster than AOF when restoring large data sets.
RDB can maximize the performance of Redis: the only thing the parent process has to do when saving the RDB file is to fork a child process, and then the child process will handle all the next save work, and the parent process does not need to perform any disk I/O operations .
disadvantage
If you need to try to avoid losing data in the event of a server failure, then RDB is not for you. Although Redis allows you to set different save points to control how often the RDB file is saved, it is not an easy operation because the RDB file needs to save the state of the entire dataset. So you may save RDB files at least once every 5 minutes. In this case, in the event of an outage, you could lose several minutes of data.
Every time the RDB is saved, Redis will fork() a child process, and the child process will do the actual persistence work. When the data set is large, fork() can be very time-consuming, causing the server to stop processing clients within a certain millisecond; if the data set is very large and CPU time is very tight, this stop time may even be long for a full second. Although AOF rewrites also require fork(), no matter how long the interval between executions of AOF rewrites is, there is no loss of data durability.
The AOF file saving process
redis will append each received write command to the file through the write function (the default is appendonly.aof).
When redis restarts, it rebuilds the contents of the entire database in memory by re-executing the write commands saved in the file. Of course, since the os will cache the modifications made by the write in the kernel, it may not be written to the disk immediately. In this way, the persistence of the aof method may still lose some modifications. However, we can tell redis through the configuration file when we want to force os to write to disk through the fsync function. There are three ways as follows (default: fsync once per second)
appendonly yes //Enable aof persistence mode
# appendfsync always //Forcibly write to disk every time a write command is received, the slowest, but guarantees complete persistence , deprecated
appendfsync everysec //Forcibly write to disk once per second, making a good compromise between performance and persistence, recommended
# appendfsync no //Completely rely on os, the performance is the best, and the way of persistence does not guarantee
aof is also at the same time brings up another problem. Persistent files can become larger and larger. For example, if we call the incr test command 100 times, all 100 commands must be saved in the file. In fact, 99 of them are redundant. Because to restore the state of the database, it is enough to save a set test 100 in the file.
In order to compress the persistent file of aof. Redis provides the bgrewriteaof command. After receiving this command, redis will use a similar way to snapshot to save the data in memory to the temporary file in the form of command, and finally replace the original file. The specific process is as follows:
redis calls fork, and now there are two processes: parent and child. The
child process writes the command to rebuild the database state into the temporary file according to the database snapshot in memory. The
parent process continues to process the client request, except that the write command is written to the original aof in the file. At the same time, the received write commands are cached. This ensures that there is no problem if the subprocess rewrite fails.
When the child process writes the snapshot content to the temporary file in command mode, the child process signals the parent process. The parent process then writes the cached write commands to the temporary file as well.
Now the parent process can replace the old aof file with a temporary file and rename it, and the write commands received later also start appending to the new aof file.
It should be noted that the operation of rewriting the aof file does not read the old aof file, but rewrites the database content in the entire memory to a new aof file by command, which is somewhat similar to the snapshot.
Advantage
Using AOF persistence makes Redis much more durable: you can set different fsync strategies, such as no fsync, fsync every second, or fsync every time a write command is executed. The default policy of AOF is fsync once per second. Under this configuration, Redis can still maintain good performance, and even if there is a failure, only one second of data will be lost ( fsync will be executed in a background thread, so The main thread can continue to work hard on the command request).
AOF file is an append only log file, so writing to AOF file does not need to seek, even if the log contains incomplete commands for some reason (such as writing to disk full, write downtime, etc.), the redis-check-aof tool can easily fix this too.
Redis can automatically rewrite AOF in the background when the size of the AOF file becomes too large: The new AOF file after rewriting contains the minimum set of commands needed to restore the current dataset. The entire rewrite operation is absolutely safe, because Redis will continue to append commands to the existing AOF file during the process of creating a new AOF file. Even if there is a shutdown during the rewriting process, the existing AOF file will not be lost. . Once the new AOF file is created, Redis will switch from the old AOF file to the new AOF file and start appending to the new AOF file.
The AOF file saves all the write operations performed to the database in an orderly manner, and these write operations are saved in the format of the Redis protocol, so the content of the AOF file is very easy to be read by people, and it is also very easy to parse the file. Exporting AOF files is also very simple: for example, if you accidentally execute the FLUSHALL command, but as long as the AOF file is not overwritten, just stop the server, remove the FLUSHALL command at the end of the AOF file, and restart Redis, The dataset can be restored to the state it was in before FLUSHALL was executed.
Disadvantages
For the same dataset, the size of AOF files is usually larger than that of RDB files.
Depending on the fsync strategy used, AOF may be slower than RDB. In general, the performance of fsync per second is still very high, and turning off fsync can make AOF as fast as RDB, even under heavy load. However, when dealing with huge write loads, RDB can provide a more guaranteed maximum latency (latency).
AOF has had such bugs in the past: due to individual commands, when the AOF file is reloaded, the dataset cannot be restored to the original state when it was saved. (The blocking command BRPOPLPUSH, for example, has caused such a bug.) Tests are added to the test suite for this situation: they automatically generate random, complex data sets and reload them to ensure everything normal. Although this kind of bug is not common in AOF files, it is almost impossible for RDB to have this kind of bug in comparison.
The choice
In general, if you want to achieve data security comparable to PostgreSQL, you should use both persistence features.
If you care a lot about your data, but can still tolerate data loss within minutes, then you can just use RDB persistence.
For the rest, I personally prefer to choose AOF
Original: http://www.cnblogs.com/rollenholt/p/3874443.html