Like other storage components, redis provides two types of persistence methods: snapshot and full append log.
RDB – snapshot
By default, redis saves the database snapshot under the name
dump.rdbIn the binary file.
You can set redis to automatically save the dataset once the condition of “at least m changes to the dataset in N seconds” is met.
You can also call
BGSAVE, manually ask redis to save the dataset.
This persistence method is called snapshot
SAVE: pause the service, write dump.rdb, for example, execute when stopping
forkSystem call to create subprocess and write dump.rdb
#Configure write policy (for bgsave): Save 900 1 # (at least one key is written in 900 seconds) Save 300 10 # (at least 10 keys are written in 300 seconds) Save 60 10000 # (at least 1000 keys are written in 60 seconds) #If RDB is not required, you can set: save "" #Set the RDB file name and storage directory dbfilename dump.rdb dir /var/lib/redis/6379
Aof – append only file (AOF)
The snapshot function is not very durable: if redis fails for some reason, the server will lose the data recently written and not saved to the snapshot.
Since version 1.1, redis has added a completely durable persistence method: AOF persistence.
Appendonly yes # (AOF enabled) appendfilename "appendonly.aof"
Whenever redis executes a command to change the dataset (such as set), this command will be appended to the end of the AOF file.
In this way, when redis is restarted, the program can rebuild the data set by re executing the commands in the AOF file.
Fsync synchronous disk brushing strategy
You can configure how often redis will fsync data to disk. There are three ways:
- Fsync is executed every time a new command is appended to the AOF file: very slow and safe
- Fsync once per second: fast enough (similar to using RDB persistence), and only 1 second of data will be lost in case of failure.
- Never fsync: leave the data to the operating system for processing. Faster and less secure options.
- The recommended (and default) measure is fsync once per second. This fsync policy can take into account both speed and security.
#Fsync synchronous disk brushing strategy #Appendfsync always # (synchronize the disk immediately, the slowest and safest) Appendfsync everysec # (only one synchronous disk brushing is triggered every second, recommended) #Appendfsync no # (without synchronous disk brushing, it is the fastest and relatively unsafe)
Because the operation mode of AOF is to continuously append commands to the end of the file, the volume of AOF file will become larger and larger with the continuous increase of write commands.
For example, if you call incr 100 times for a counter, the AOF file needs to use 100 entries just to save the current value of the counter.
However, in practice, using only one set command is enough to save the current value of the counter, and the remaining 99 records are actually redundant.
To handle this situation, redis supports an interesting feature: you can rebuild the AOF file without interrupting the service client.
BGREWRITEAOFCommand, redis will generate a new AOF file, which contains the minimum commands required to rebuild the current dataset.
#Configuration: bgrewriteaof will be triggered every time the AOF file grows by a percentage of the specified size auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb
Since redis 4.0, AOF rewrite logic has changed:
- Old data adopts RDB
forkWrite header of AOF file
- Subsequent incremental commands are appended to the end of the AOF file
In this way, AOF is a hybrid, which makes use of the speed of RDB and the full amount of logs, making redis persistence more secure and perfect.