RDB: Can take snapshots of your data for storage at specified intervals.
AOF: records each write operation to the server, and re-executes these commands when the server restarts to restore the original data.
In this article, we will present the following content in the hope of providing a more comprehensive and clear understanding of these two persistence methods, as well as understanding this way of thinking about saving data to apply to your own system design.
How RDB works with AOF persistence
How to recover data from persistence
Recommendations on performance and practice
In order to use the persistence feature, we need to know how to turn on persistence first.
RDB persistence configuration
# Time strategy
save 900 1
save 300 10
save 60 10000
# File name
# File save path
# If there is a persistence error, does the master process stop writing
# Whether to compress
# Whether or not to check when importing
The configuration is actually very simple, here's what exactly the persistent time policy means.
save 900 1 This means that if there is 1 write command in 900s, it will trigger a snapshot, which can be interpreted as a backup.
save 300 10 means that 10 writes in 300s produce a snapshot
The following is similar, so why do you need to configure so many rules? Since Redis is certainly not balanced in terms of read and write requests per time slot, to balance performance with data security, we are free to customize when a backup is triggered. So here's where it makes sense to configure it based on your own Redis writes.
stop-writes-on-bgsave-error yes This configuration is also a very important one, this is to stop the main process from accepting new write operations when the backup process fails, it is to protect persistent data consistency issues. If your business has a well-developed monitoring system, you can disable this configuration. Otherwise, please turn it on.
About the configuration of the compression rdbcompression yes It is not necessary to turn it on, after all, Redis itself is a CPU-intensive server, and turning on compression again will bring more CPU consumption, which is worth more than the cost of the hard disk.
Of course if you want to disable the RDB configuration, it is very easy to do so, just write on the last line of the savesave ""
Configuration of AOF
# Whether to turn on aof
# File name
# Synchronization methods
# whether aof is synchronized during rewrites
# Rewrite the trigger configuration
# What to do if there is an error when loading aof
# File rewrite policy
Still focusing on explaining some key configurations.
appendfsync everysec It actually has three modes :
always: sync every write command to aof immediately, very slow, but safe
everysec: one sync per second, a compromise
no: redis doesn't handle it to the OS, very fast but also the least secure
It is generally used everysec configuration, which allows for a balance of speed and security, with a maximum loss of 1s of data.
aof-load-truncated yes If this configuration is enabled, a log will be written to the client when the aof tail is found to be incorrect on load, but will continue to execute if set to no , the error is found and it stops and must be fixed before it can be reloaded.
For the principles section, we will mainly look at how RDB and AOF accomplish persistence and how their process works.
Before describing the principle, let's talk about Redis's internal timing mechanism. The frequency of timing task execution can be specified in the configuration file via hz 10 to set (this configuration indicates 10 executions in 1s, which means that the timed task is triggered every 100ms). This value can be set to a maximum of.500 However, it is not recommended to exceed.100 The higher the value, the more frequent and higher the execution frequency, which brings more CPU consumption and thus affects the read/write performance of the main process.
The timed tasks use Redis' own implementation of TimeEvent It will regularly call commands to complete timed tasks that may block the main process causing Redis performance to degrade. So when we configure Redis, we must consider some of the configurations that will trigger timed tasks as a whole and adapt them to the actual situation.
Principle of RDB
There are two types of triggers for RDB persistence in Redis: your own manual trigger and Redis timed trigger.
For the RDB approach to persistence, the manual trigger can be used.
save: will block the current Redis server until persistence is complete, and should be disabled on line.
bgsave: This trigger method forks a child process, which is responsible for the persistence process, so blocking will only occur when forking the child process.
but (not) auto-trigger The main scenarios are the following：
According to our save m n Automatic triggering of configuration rules.
When a slave node is fully replicated, the master node sends an rdb file to the slave node to complete the replication operation, and the master node triggers bgsave；
execute debug reload Hours.
execute shutdownWhen aof is not turned on, it will also trigger.
thanks to save It's basically not going to be used, so let's focus on bgsave This command is how RDB persistence is accomplished.