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

This article introduces the knowledge of "how to configure snapshot persistence in Redis". Many people will encounter this dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Redis persistence

On the whole, there are two ways of redis persistence, snapshot persistence and AOF. In the project, we can choose the appropriate persistence method according to the actual situation, or we do not need persistence, which depends on what role our redis plays in the project. So I'll use two articles to introduce these two different persistence methods. In this article, let's take a look at the first one.

Snapshot persistence

Snapshot persistence, as the name implies, is to achieve data persistence by taking snapshots. Redis can create a copy file of the data in memory at a certain point in time, and the data in the copy file will be automatically loaded when redis restarts. We can also copy the copy file to other places.

How to configure snapshot persistence

Snapshot persistence in redis is enabled by default. The related configurations in redis.conf are mainly as follows:

Save 900 1save 300 10save 60 10000stop-writes-on-bgsave-error yesrdbcompression yesdbfilename dump.rdbdir. /

The first three save-related options indicate the frequency of backups, respectively, indicating that at least one key is changed within 900s, at least 10 keys are changed within 300s, and at least 10000 keys are changed within 60 seconds. Stop-writes-on-bgsave-error indicates whether to continue to execute the write command after the snapshot creation error, and rdbcompression indicates whether to compress the snapshot file. Dbfilename represents the name of the generated snapshot file, and dir indicates the location of the generated snapshot file. In redis, snapshot persistence is enabled by default. We can verify the effect of snapshot persistence by following these steps:

1. Enter the redis installation directory and delete the dump.rdb file first if there is any. As follows:

! [p299] ()

two。 Start redis, store a few pieces of data in redis at will, then close redis and exit, as follows:

[root@localhost redis-4.0.8] # redis-server redis.conf [root@localhost redis-4.0.8] # redis-cli127.0.0.1:6379 > set K1 v1OK127.0.0.1:6379 > set K2 v2OK127.0.0.1:6379 > SHUTDOWNnot connected > exit

3. After checking out, we found that the dump.rdb file that had just been deleted came back, and this was the backup file that was generated.

4. At this point, start redis again and enter, and find that the data just stored is still there, because redis loads the data in dump.rdb when it starts. All right, close redis and exit.

5. Delete the dump.rdb file in the redis directory.

6. Start redis again and go to the console, and all the data is gone.

Snapshot persistence operation flow

Through the above introduction, friends have a general understanding of snapshot persistence, so how does this thing work? What is the timing of persistence? Let's pick it carefully.

1. When redis is running, we can send a save command to redis to create a snapshot. Save is a blocking command. After receiving the save command and starting the backup operation, redis will not process other requests until the backup operation is completed, and other requests will be suspended, so we do not use this command much. The save command is executed as follows:

127.0.0.1 purl 6379 > SAVEOK

two。 When redis is running, we can also send a bgsave command to create a snapshot. Unlike the save command, the bgsave command will fork a child process, and then the child process will be responsible for writing the snapshot to the hard disk, while the parent process will continue to process the request from the client, so that the client command will not be blocked. As follows:

127.0.0.1 purl 6379 > BGSAVEBackground saving started

3. If we configure the following options in redis.conf:

Save 900 1save 300 10save 60 10000

Then when the conditions are met, for example, a key is operated within 900 seconds, then the redis will automatically trigger the bgsava command for backup. We can configure several of these trigger rules in redis.conf according to the actual requirements.

4. Another situation that triggers the save command is that when we execute the shutdown command, when we close the redis with the shutdown command, we also execute a save command to back up and shut down the server after the backup operation is complete.

5. There is also a special case that triggers the bgsave command, that is, when a master-slave backup is made. When the slave is connected to the host, a sync command is sent to start a replication operation, and the host starts a bgsave operation and sends snapshot data to the slave for data synchronization after the bgsave operation ends.

Disadvantages of snapshot persistence

Snapshot persistence has some disadvantages, such as save command blocking, bgsave does not block, but a fork child process consumes resources, and in some extreme cases, the time of the fork child process even exceeds the time of data backup. Regular persistence also gives us the risk of data loss. In the worst case, we may lose the data that was last backed up to the present. How long the data is lost depends on the affordability of our project. We can configure save parameters according to the affordability of the project.

That's all for "how to configure snapshot persistence in Redis". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.