RDB and AOF in Redis
We all know that Redis runs with data stored in memory, if the server is down or restarted, then the data in memory will be lost, thus affecting the normal operation of the business. Therefore, we must persist the data to disk, so that when the server fails to restore the data.Redis in the persistence, gives us two ways, these two ways are RDB and AOF.
RDB
RDB, which stands for RedisDB, is a persistence method that persists the entire Redis in-memory data into an .rdb file. It holds the Redis dataset at a certain point in time, and this dataset file is great for backups - for example, you could have an hourly backup of the .rdb file, and a daily backup of the .rdb file at 24:00. This way, you can always restore the dataset to a different version if something goes wrong. At this point, some of you may be asking, "What if the data in memory is modified while Redis is doing persistence? For example, if the data started out as A, but changed from A to B during persistence, what is the value that was eventually persisted to the .rdb file? π" This is a good question, let's reveal it π!
π§Let's reveal it together.π§
Before revealing the secret, we need to mention a small knowledge point, I do not know if you have ever used the fork function under Linux. fork function is the Linux function to create a child process. The fork function is a Linux function that creates a child process. It creates a child process by copying the main process, and when the fork function is called, the child process and the main process have the same data content, and the two processes run in their own memory spaces without affecting each other. So the child process retains the state of the data at the beginning of the persistence. So, for the problem above, the persisted data will still be A.
Regarding RDB, Redis provides two ways to use it, namely, command and configuration file. If we choose to use commands, we can use the save and bgsave commands to trigger persistence operations; of course, we can also choose to use configuration files to carry out persistence, for example, you can modify the Redis configuration file to save 100 10 (10 keys are modified within 100 seconds to trigger persistence), save 60 10000 (60 seconds), and so on. save 60 10000 (save 60 10000 (save 60 10000), etc.).
With the above, we can also summarize some of the advantages and disadvantages of RDB π
πvantageπ
π β RDB is great for disaster recovery. It has only one file and the contents are very compact, which makes it easier to maneuver during data recovery.
π β‘ RDB maximizes Redis performance. The only thing the parent process has to do when saving an RDB file is fork a child process, which then handles all the subsequent saving without the parent having to perform any disk I/O operations.
πdrawbacksπ
π₯ β If you need to try to avoid losing data in the event of a server failure, then we'd be better off without RDB. Although Redis allows you to set different save points to control the frequency of saving RDB files, RDB files require saving the state of the entire dataset, so it is not an easy operation. So it can take at least 5 minutes or more to save an RDB file once. In this case, then, in the event of a failure and downtime, several minutes of data may be lost.
Then if the dataset is large, the fork operation can be very time-consuming and may cause the server to stop processing client requests for a number of milliseconds; this stopping time may even be longer if the dataset is very large and CPU time is very tight.
AOF
Let's take a look at AOF after we understand RDB, it is similar to the statement mode of Binlog, AOF will record each step of data modification in Redis to the corresponding file. In order to reduce I/O consumption, AOF writes data to a buffer first and then writes the contents of the buffer to disk in a process called fsync, which can be set to different fsync policies π.
appendfsync always : every write operation writes to disk, but affects performance appendfsync everysec : writes once per second (Default Policy for AOFappendfsync no: wait negatively for OS refresh (usually 30s), but data may be lost.
Redis can automatically rewrite the AOF file in the background when it becomes too large, since the AOF file will inevitably grow larger as the server runs longer. The new AOF file contains the minimum set of commands needed to recover the current dataset. The entire rewrite operation is completely safe because Redis continues to append commands to the existing AOF file while creating the new AOF file, so even if there is downtime during the rewrite process, the existing AOF file will not be lost. Once the new AOF file is created, Redis switches from the old AOF file to the new AOF file and starts appending to the new AOF file.
With the above understanding, we can also summarize some of the advantages and disadvantages of AOF π
πvantageπ
π β Not easy to lose data, good data integrity. We can set the fsync policy, which is usually everysec by default, or we can set append per write, so even if the service goes down, it will lose at most one second of data.
πdrawbacksπ
π₯ β Relatively poor performance: its mode of operation dictates that it will be a performance drain on Redis.
π₯ β‘ Since the AOF file is larger, it results in slower data recovery.
wrap-up
I have limited experience, some places may not speak particularly to the point, if you think of any problems when reading, welcome to leave a message in the comments section, we will follow up to discuss πβ
If there are errors in the article, welcome to leave a message to correct; if you have a better, more original understanding, you are welcome to leave your valuable ideas in the message area.
To this article about an article to take you to understand the difference between Redis RDB and AOF article is introduced to this, more related to the difference between Redis RDB and AOF content please search for my previous articles or continue to browse the following related articles I hope that you will support me more in the future!