Shulou(Shulou.com)06/01 Report--

Redis persistence of how to understand, I believe that many inexperienced people are helpless about this, this article summarizes the causes and solutions of the problem, through this article I hope you can solve this problem.

We all know that Redis is an in-memory database, and all data is stored in memory. Once the Redis process exits on the server, the data in the database is lost.

What does persistence do? Persistence is simply understood as making a backup of data in memory. There are two ways to persist Redis: RDB persistence and AOF persistence. These two persistence methods, and how they work, are described in two parts.

I. RDB Persistence

Redis data persistence is to save data in memory to disk to avoid accidental data loss. RDB persistence generates an RDB file, which is a compressed binary file. This file can be used to restore data from the Redis database. Persistence of RDBs can be performed manually or automatically on a periodic basis based on server configuration items.

Let's learn how RDB files are created. There are two commands to create an RDB file, SAVE and BGSAVE.

Executing the SAVE command blocks the Redis server process until the RDB file is created, and the server cannot process any command requests while the server process is blocked.

Executing the BGSAVE command spawns a child process, which then creates the RDB file, and the server parent process continues to process the command request.

The SAVE command and the BGSAVE command call the same function rdbSave, except that the SAVE command calls this function directly, while BGSAVE forks () out the child process to call this function. The pseudocode is as follows:

The loading of RDB files is performed automatically at server startup, as long as Redis server detects the existence of RDB files at startup, it will automatically load RDB files. It is worth mentioning that the Redis server blocks during the loading of the RDB file until the loading is complete.

The BGSAVE command executes without blocking the server process, so Redis allows users to have the server automatically execute the BGSAVE command once in a while by setting the server's save option.

The BGSAVE command will be executed if one of the above conditions is met:

BGSAVE is executed if the server has modified the database at least once in 900 seconds

BGSAVE is executed if the server has modified the database at least 10 times in 300 seconds

The BGSAVE command is executed if the server has made at least 10000 changes to the database in 60 seconds.

II. AOF Persistence

In addition to RDB persistence, Redis also provides AOF persistence, which is implemented in a very different way. RDB persistence records database state by saving key-value pairs in the database, while AOF persistence records database state by saving write commands executed by Redis servers.

How does AOF persistence work? AOF persistence consists of three steps: command appending, file writing, file synchronization.

Command appending: When AOF persistence is enabled, the server appends the executed write command to the aof buffer in the server in a certain format after executing a write command. The aof buffer is an attribute of an SDS structure maintained by the redisServer structure.

File writes: File writes are written from Redis aof buffer to the operating system memory buffer. This procedure is intended to improve file writing efficiency, but carries the risk that data in memory buffers will be lost in the event of a server failure.

File synchronization: This process is to write data from memory buffers to AOF files on hard disk

The default implementation in Redis is RDB persistence. How to turn on AOF persistence? Let's first look at the AOF configuration items:

①appendonly: This parameter is the switch of AOF. If configured as yes, the persistence mechanism of AOF can be turned on. After opening the AOF mechanism

appendfsync: We know that Redis has an event loop, and Redis writes the contents of the aof buffer to the operating system memory buffer in each event loop. This parameter is used to configure the update frequency of synchronizing the data in the memory buffer to the AOF file on the hard disk. There are always, everysec, and no three configuration values.

always means that every time a write operation is performed, the contents of the memory buffer are immediately synchronized to the AOF file on disk. This configuration has poor performance, but ensures that data is not lost.

Everysec means that the data in the memory buffer of the operating system is synchronized to the AOF file on disk once per second. This operation is responsible for a thread and has high performance.

No indicates that the operating system controls when data in memory buffers is synchronized to AOF files on the hard disk. This operation can result in loss of data when the server is abnormal.

Let's talk about the restoration process of the AOF file. We know that the AOF file stores all the write commands that have been executed, so the server can restore the database contents before the server is closed as long as it reads and re-executes the write commands saved in the AOF file.

At the same time, in order to solve the problem that AOF files are getting larger and larger during Redis operation, Redis also provides AOF rewriting function. The principle of AOF rewriting is not specifically introduced here. Interested parties can discuss it privately.

III. Distinctions and connections between RDB and AOF, and the situation when they work simultaneously

First of all, let's summarize the differences and connections between the two ways:

RDB Persistence: On by default; Full backup, save the entire database at one time; Small size, fast data recovery; Some data may be lost when the server is abnormal;SAVE operation will block, BGSAVE does not block

AOF persistence: default off; incremental backup, save one command to modify the database at a time; large volume, slow data recovery; backup frequency can be set by yourself; no blocking

When RDB and AOF start simultaneously:

redis does not perform an AOF rewrite if RDB is performing snapshotting; redis does not perform RDB snapshotting if redis performing an AOF rewrite

If the RDB is snapshotting and the user executes the BGREWRITEAOF command, AOF rewrite will not be executed until the RDB snapshot is generated

At the same time, there are RDB snapshot files and AOF log files. When redis restarted, AOF will be used first for data recovery because the logs are more complete.

After reading the above content, do you know how to understand Redis persistence? If you still want to learn more skills or want to know more related content, welcome to pay attention to the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.