Persistence of Redis

Persistence is to keep our data intact and to store it on our hard disk. There are two ways of persistence in Redis, one is snapshot persistence, the other is AOF persistence, each has its own advantages and disadvantages, in the project we have to choose the specific persistence method according to the actual situation.

This blog focuses on snapshot persistence (rdb file)

Snapshot persistence

Also known as rdb persistence mode, data persistence is achieved by taking snapshots and storing data in an rdb file for a certain period of time. When redis service is restarted, data will be loaded from the rdb file.

Configure snapshot persistence

The default persistence is on, in the redis-conf file

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""

save 900 1   #Take snapshots when at least one key has been changed in 900 seconds
save 300 10  #In 300, snapshots are executed when at least 10 key s have been changed
save 60 10000  #Take snapshots when at least 10,000 key s have been changed in 60 seconds

# By default Redis will stop accepting writes if RDB snapshots are enabled
# (at least one save point) and the latest background save failed.
# This will make the user aware (in a hard way) that data is not persisting
# on disk properly, otherwise chances are that no one will notice and some
# disaster will happen.
#
# If the background saving process will start working again Redis will
# automatically allow writes again.
#
# However if you have setup your proper monitoring of the Redis server
# and persistence, you may want to disable this feature so that Redis will
# continue to work as usual even if there are problems with disk,
# permissions, and so forth.
stop-writes-on-bgsave-error yes #Do you continue to execute the write command if the snapshot failed?

# Compress string objects using LZF when dump .rdb databases?
# For default that's set to 'yes' as it's almost always a win.
# If you want to save some CPU in the saving child set it to 'no' but
# the dataset will likely be bigger if you have compressible values or keys.
rdbcompression yes #Whether to compress snapshot files

# Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
# This makes the format more resistant to corruption but there is a performance
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it
# for maximum performances.
#
# RDB files created with checksum disabled have a checksum of zero that will
# tell the loading code to skip the check.
rdbchecksum yes #Data validation

# The filename where to dump the DB
dbfilename dump.rdb #Name of snapshot file store
# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir ./ #Location of snapshot file storage

At this point, we shut down the service, restart it again, and get the key value.

Exit and clear the rdb file, restart, and the data is cleared

Reboot, data cleared

Principle of Snapshot Persistence

save

In redis, we can send a Save command to take a snapshot. The Save command is a blocking command, that is, when the server receives a save command, it starts taking snapshots, during which no other requests are processed, and other requests are suspended until the end of the backup.

bgsave

The bgsave command also takes a snapshot immediately. Unlike the save command, bgsave is not a blocking command, but a fork sub-thread, which is responsible for backup operations. The parent process continues to process the client's requests so that there is no blocking.

shutdown

When we just want the shutdown command. The server automatically sends a save command to complete the snapshot operation. Close the server after the backup operation is completed. So when we shut down the server when our operation does not meet the first three conditions, we can open our data again without losing it.

Advantages and disadvantages of persistent snapshots

Advantage

RDB file is a very concise single file, which saves Redis data at a certain point in time and is suitable for backup. You can set a time point to archive RDB files so that you can easily restore data to different versions when needed.
RDB is well suited for disaster preparedness. A single file can be easily transferred to a remote server.
RDB has good performance. When it needs to be persisted, the main process fork s out a sub-process, and then gives the persistence work to the sub-process, which has no relevant I/O operation.
Compared with AOF, RDB starts faster when the data is large.

shortcoming

RDB is prone to data loss. Assuming that a snapshot is saved every five minutes, if Redis does not work properly for some reason, the data will be lost between the last snapshot and Redis problems.
RDB uses fork() to generate subprocesses for data persistence, which may take a little time if the data is large, causing Redis to stop serving for several milliseconds. If the amount of data is large and the CPU performance is not very good, the time to stop the service may even be 1 second.

Disable snapshot persistence

1. Comment out all save configurations in redis.conf configuration file
2. Append this command to the last save configuration

save ""
#save 900 1   #Take snapshots when at least one key has been changed in 900 seconds
#save 300 10  #In 300, snapshots are executed when at least 10 key s have been changed
#save 60 10000  #Take snapshots when at least 10,000 key s have been changed in 60 seconds