What is persistence, is to store data in a device that will not be lost after a power failure, usually a hard disk
Common persistence methods:
Master-slave: save and persist through the slave server, such as mongodb's replication sets configuration
Log: The operation generates related logs and restores data through the logs
CouchDB does not modify the data content, but only appends, and the file itself is a log, and no data will be lost.
Redis persistence method one:
Rdb snapshot persistence: after every N minutes or N write operations, dump data from the memory to form an rdb file, compress it and place it in the backup directory. Note that the red font part can be configured through parameters. The exported image is the memory image, so restore high speed.
The above-mentioned persistence method has defects. If the power is interrupted between the two save points, at least 1-N minutes of data will be lost. Therefore, due to the finer requirements for persistence, redis adds the aof method (append only file ) To ensure redis persistence
Aof log persistence: When the database is operating, the redis main process is responsible for responding, and the background process will save the generated commands into the log file, but not every command generated must be saved in, this may greatly reduce the data storage Speed, a compromise solution can be set to save the log every second, of course, the specific configuration is also through the parameters, and log persistence and RDB persistence can be combined to use in order to achieve better results, in RDB persistence When in progress, the aof log writing can be suspended, and the log data is stored in the queue so that after the RDB persistence is completed, the log information will be written to the file from the queue.
Aof rewrite: In actual use, there may be a situation where the value of a key becomes the value in the current memory after hundreds of times of the same operation, but whether it is aof or not, all these commands must be changed All are written into the log file. In fact, this approach is not advisable. When aof is written to the log file, the specific state of the key in the memory will be reversed into a command and written into the log file. Regardless of how many times this state is obtained through the same operation, this operation is called AOF rewriting. After AOF rewriting, the log file will be greatly reduced, which solves the problem of excessive logs. Then when do you start to rewrite? This can be configured by parameters in the configuration file. (Auto-aof-rewrite-percent 100 The file size has increased by 100% compared to the size of the last rewrite. auto-aof-rewrite-min-size 64mb. Rewrite when the aof file exceeds 64M at least)
There may be questions about the two types of persistence:
1. Will AOF be lost if synchronization is stopped during the dump rdb process?
No, because all operations are cached in the memory queue, and the operations are unified after the dump is completed
2. If the rdb file and the aof file exist at the same time, who should be used first to restore the data?
Aof, the reason is mentioned in rdb persistence, rdb persistence has defects
3. When recovering, which one of rdb or aof recovers quickly?
rdb is fast, because it is a memory mapping of data, directly loaded into the memory, and aof is a command, which needs to be executed