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

Compared with other cache products such as Memcache, Redis has an obvious advantage that Redis not only supports simple key-value type data, but also provides storage of data structures such as list,set,zset,hash. We have spent two articles on these rich data types, and then we will introduce another major advantage of Redis-persistence.

Because Redis is an in-memory database, the so-called in-memory database is to save the contents of the database in memory. Compared with the traditional relational database such as MySQL,Oracle, the read-write efficiency of the in-memory database is much faster than that of the traditional database (the read-write efficiency of the memory is much higher than that of the hard disk). However, saving in memory also brings a disadvantage, once the power outage or downtime, then all the data in the in-memory database will be lost.

To solve this disadvantage, Redis provides the ability to persist in-memory data to the hard disk and to recover database data with persistent files. Redis supports two forms of persistence, one is RDB snapshot (snapshotting), and the other is AOF (append-only-file). This blog first introduces RDB snapshots.

1. Introduction to RDB

RDB is a way for Redis to persist by writing a snapshot of the dataset currently in memory to disk, that is, the Snapshot snapshot (all key-value pairs in the database). When restoring, the snapshot file is read directly into memory.

Back to the top.

2. Trigger mode

There are two ways to trigger RDB, which are automatic trigger and manual trigger.

①, automatic trigger

Under SNAPSHOTTING in the redis.conf configuration file

①, save: this is used to configure the RDB persistence condition that triggers Redis, that is, when the data in memory is saved to the hard disk. Such as "save m n". Indicates that bgsave is automatically triggered when there are n modifications to the dataset within m seconds (this command is described below, the command that manually triggers RDB persistence)

The default configuration is as follows:

Save 9001: if there is a change in the value of at least one key in 900s, save save 30010: if there is a change in the value of at least 10 key in 300s, save save 60 10000: it means that if there is a change in the value of at least 10000 key in 60 seconds, save it

Of course, if you only use Redis caching without persistence, you can comment out all save lines to disable the save feature. Deactivation can be achieved by directly using an empty string: save ""

②, stop-writes-on-bgsave-error: the default value is yes. Whether Redis stops receiving data when RDB is enabled and the last time the data is saved in the background fails. This will make the user realize that the data is not correctly persisted to disk, otherwise no one will notice that a disaster has occurred. If Redis is restarted, you can start receiving data again.

③, rdbcompression; default is yes. For snapshots stored on disk, you can set whether to compress storage. If so, redis uses the LZF algorithm for compression. If you don't want to consume CPU for compression, you can set this feature to off, but the snapshots stored on disk will be larger.

④, rdbchecksum: the default value is yes. "after storing the snapshot, we can also have redis use the CRC64 algorithm for data validation, but doing so increases performance consumption by about 10%, which can be turned off if you want to get the maximum performance improvement."

⑤, dbfilename: sets the file name of the snapshot. Default is dump.rdb.

⑥, dir: set the path where snapshot files are stored. This configuration item must be a directory, not a file name. The default is saved in the same directory as the current configuration file.

In other words, through the save method configured in the configuration file, RDB persistence will be carried out when the actual operation meets the configuration form, and the current memory snapshot will be saved in the directory of the dir configuration, and the file name is determined by the configured dbfilename.

②, manual trigger

There are two kinds of commands that manually trigger Redis for RDB persistence:

1 、 save

This command blocks the current Redis server, and during the execution of the save command, Redis cannot process other commands until the RDB process is complete.

Obviously, this command can cause long-term blocking for instances with large memory, which is a fatal flaw, and Redis provides a second way to solve this problem.

2 、 bgsave

When executing this command, Redis performs snapshot operations asynchronously in the background, and snapshots can also respond to client requests. The specific operation is that the Redis process executes the fork operation to create the child process, and the RDB persistence process is responsible for the child process, which ends automatically after completion. Blocking occurs only in the fork phase, usually for a short time.

Basically all RDB operations within Redis use the bgsave command.

Ps: executing the flushall command will also generate a dump.rdb file, but it is empty and meaningless

3. Restore data

Just move the backup file (dump.rdb) to the redis installation directory and start the service, and redis will automatically load the file data into memory. The Redis server will remain blocked during the loading of the RDB file until the loading is complete.

To get the installation directory of redis, you can use the config get dir command

4. Stop RDB persistence

In some cases, we just want to take advantage of Redis's caching, not Redis's persistence, so we'd better stop RDB persistence at this time. You can disable the save function by commenting out all the save lines in the configuration file redis.conf as mentioned above, or simply an empty string to deactivate: save ""

You can also use the command:

Redis-cli config set save ""

Back to the top.

5. Advantages and disadvantages of RDB

①, advantage

1.RDB is a very compact file that holds the dataset of redis at some point in time. This kind of file is ideal for backup and disaster recovery.

two。 When the RDB file is generated, the fork main process will fork () a child process to handle all the save work, and the main process does not need to do any disk IO operation.

3.RDB recovers large datasets faster than AOF does.

②, disadvantage

1. RDB data cannot be persisted in real time / seconds. Because every time bgsave runs, it has to perform the fork operation to create a child process, which is a heavyweight operation (a copy of the data in memory is cloned, approximately 2 times the expansibility needs to be considered), and the cost of frequent execution is too high (affecting performance).

2. RDB files are saved in a specific binary format. During the evolution of Redis versions, there are multiple RDB versions of formats. There is a problem that the old version of Redis service is not compatible with the new version of RDB format (the version is not compatible).

3. Make a backup at regular intervals, so if redis accidentally down, all changes since the last snapshot will be lost (data is lost)

Back to the top.

6. The principle of RDB automatic saving.

Redis has a server status structure:

Struct redisService {/ / 1, the array struct saveparam * saveparams; / / 2 that records the save conditions, the modification counter long long dirty; / / 3, the last time the save was performed time_t lastsave;}

①, first look at the array saveparam that records the save conditions, where each element is a saveparams structure:

Struct saveparam {/ / seconds time_t seconds; / / modified int changes;}

We configured save in the redis.conf configuration file earlier:

Save 9001: if there is a change in the value of at least one key in 900s, save save 30010: if there is a change in the value of at least 10 key in 300s, save save 60 10000: it means that if there is a change in the value of at least 10000 key in 60 seconds, save it

Then the saveparam array in the server state will look like this:

②, dirty counters, and lastsave properties

The dirty counter records how many modifications (including writes, deletions, updates, etc.) have been made by the Redis server since the last successful execution of the save command or bgsave command.

The lastsave attribute is a timestamp that records the last time a save command or bgsave command was successfully executed.

With these two commands, when the server successfully performs a modify operation, then the dirty counter will be incremented by 1, and the lastsave property records the time when the last save or bgsave was executed, and the Redis server also has a periodic operation function severCron, which is executed every 100ms by default, which traverses and checks all the save conditions in the saveparams array, and executes the bgsave command as long as a condition is met.

After the execution is complete, the dirty counter is updated to 0, and the lastsave is updated to the completion time of the execution command.

These are the details of RDB persistence in redis. Please pay attention to other related articles!

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.