About the persistence mechanism RDB in Redis

Introduction: This is my second article on getting Started

There are two persistence schemes in Redis: RDB (Redis DataBase) and AOF (Append Only File). This article explains the mechanism of RDB in a more basic way.Copy the code

Introduction of RDB

What is RDB?

RDB is a method of persistence used by Redis by writing a Snapshot of a data set in memory to disk at a specified interval, also known as a Snapshot Snapshot. When Redis recovers, files are read directly into memory.

How does the backup work

Redis creates a separate (Fork) process for persistence, writing data to a temporary file that will replace the last persisting file when the persisting process is over. No IO is performed by the main process during the entire process, which ensures extremely high performance. The RDB approach is a good choice for large-scale data recovery and is not sensitive to data integrity, but the data may be lost after the last time the RDB was persisted.

For example, RDB is still persisting and has been backed up to the last operation. When RDB is reading half of the data, Redis suddenly crashes and RDB cannot read data from Redis. As a result, the last persisting data is incomplete.

RDB triggering mode

RDB can be set to trigger automatically and manually (the default is automatic).

  • The save command blocks the current Redis server. During the save command, Redis cannot process other commands until the RDB process is complete. Redis provides a second way to solve the problem of blocking for long periods of time on large instances of memory.
  • Bgsave When this command is executed, Redis performs snapshot operations asynchronously in the background. The snapshot can also respond to client requests. The Redis process forks to create a child process. The child process is responsible for the RDB persistence process and automatically terminates after the RDB persistence process is complete. Blocking occurs only in the fork phase, usually for a short time.

Related Configuration Items

  • The default setting for save is to create a snapshot if the snapshot is changed once in 900 seconds, 10 times in 300 seconds, and 10,000 times in 60 seconds. Of course, you can set your own Settings.

  • Stop -writes-on-bgsave-error The default value is yes. Whether Redis stops receiving data when RDB is enabled and the last data saving in the background fails. This will make the user aware that the data is not persisted correctly to disk, otherwise no one will notice that a disaster has occurred. If Redis restarts, it can start receiving data again

  • The default value of rdbcompression is yes. You can set whether to compress snapshots stored on disks. If so, Redis uses the LZF algorithm for compression (which simply means that the instructions of the same type are executed together). You can turn this off if you don’t want to consume CPU for compression, but snapshots stored on disk will be large.

  • Rdbchecksum is yes by default. After the snapshot is stored, the database starts to determine whether the snapshot is damaged. If the snapshot is damaged, the database stops starting. This may cost performance, but you can turn it off if you want the highest performance possible.

The RDB file is restored

When the Redis server is started, if the Redis root directory has an RDB file dump. RDB, Redis will automatically load the RDB file to restore persistent data.

Verify that the RDB file is loaded

*DB loaded from dis:0.000 seconds *DB loaded from dis:0.000 seconds

Tip: Also, the Redis server will be blocked during loading until the work is complete.

RDB pros and cons

Advantages of RDB

  • The content of the RDB is binary data, which occupies less memory, is more compact, and is more suitable for backup files
  • The RDB provides fast data recovery and is suitable for large-scale data recovery.
  • The RDB is persisted using copy-on-write technology, which allows the redis main process to generate RDB files without any disk I/O operations.

RDB disadvantage

  • The RISK of RDB data loss is high
  • The RDB is saved in a specific binary format. During the version evolution process, the RDB version in multiple formats is not compatible with the new version
  • RDB often needs to fork a child process to save the data set to disk. When the data set is large, the fork process is time-consuming, which may cause Redis to fail to respond to client requests in some milliseconds.