NOSQL Redis data persistence RDB, AOF (1) backup file

View redis version

Redis configuration file

Modify the default file name and default storage path of dump.rdb

Redis data persistence

1. Snapshot mode (RDB, Redis DataBase) Full snapshot storage of your data at specified time intervals.
2. File append mode (AOF, Append only File) increment
   Record each write operation to the server. When the server is restarted, these commands will be re-executed to restore the original data.
3. Hybrid persistence mode (redis 4 default mode)

RDB snapshot method

The way to achieve a photo-like recording effect is to write the data and status at a certain moment on the disk in the form of a file, which is a snapshot. Even if there is a downtime, the snapshot will not be lost and the reliability of the data is guaranteed. The snapshot file is an RDB file (dump.rdb).

① Write the snapshot of the data set in the memory to the disk within the specified time interval, that is, the Snapshot memory snapshot. To recover, the hard disk snapshot file is directly read back into the memory.

②Redis data is all in the memory. When saving the backup, it performs a full snapshot, that is, it stores all the data in the memory to the disk.

③The file saved by RDB is dump.rdb.

Trigger strategy

① Manually trigger two commands
Manual save command: You can perform a persistent save immediately by executing the save command in the redis-cli client. The save command will block the redis-server process during execution until the persistence process is completed. And in redis-server
While the process is blocked, Redis cannot process any read or write requests and cannot provide external services. Online use prohibited
Manual bgsave command: A persistent save can be performed immediately by executing the bgsave command in the redis-cli client. Different from the save command, just like the name of the command, background save runs save in the background. The bgsave command will cause the server process redis-server
A child process will be forked, and the child process will be responsible for completing the saving process. During the saving process of the child process, redis-server will not be blocked
The process handles client read and write requests.

②The essence of automatic condition triggering: it is the execution of the bgsave command.
After the user makes corresponding settings in the configuration file, Redis will automatically call the bgsave command based on the setting information.
For RDB persistence, we generally use BGSAVE for persistence, after all, it does not block the server process.
In the Redis configuration file, it is provided to set how often the server executes the BGSAVE command.
Redis default configuration is as follows:
save 900 1 // Within 900 seconds, modify the database at least once. The same applies to the following
save 300 10
save 60 10000
As long as one of these conditions is met, the server will execute the BGSAVE command.

Advantage:
① Suitable for large-scale data recovery, dump.rdb is compressed, and recovery is relatively fast
② Schedule backup according to business,
③Those who do not have high requirements for data integrity and consistency and do not need second-level backup
④RDB files are loaded into memory faster than AOF.

Disadvantages:
① Make a backup at a certain interval. If redis crashes unexpectedly, the data from the current to the latest snapshot will be lost, and the data between snapshots will be lost;
②Full synchronization of memory data. If the amount of data is too large, I/O will seriously affect service performance.
③RDB relies on the fork of the main process, which may cause an instant delay in service requests on larger data sets. When forking, the data in the memory is cloned and expanded roughly twice. Need to consider.

RDB persistence configuration

# Time strategy
save 900 1
save 300 10
save 60 10000

# file name
dbfilenamedump.rdb

# File save path
dir /home/work/app/redis/data/

# If a persistence error occurs, whether the main process stops writing
stop-writes-on-bgsave-error yes
# Whether to compress
rdbcompression yes
# Whether to check when importing
rdbchecksum yes

rdb corresponding configuration parameters
rdbcompression yes
The default is yes. For snapshots stored on disk, you can set whether to compress and store them. If so, redis will use the LZF algorithm for compression.
If you don’t want to consume CPU for compression, you can set it to turn off this function.
stop-writes-on-bgsave-error yes
Default yes
If configured to no, it means that you don’t care about data inconsistency or have other means to discover and control such inconsistencies.
Then when the snapshot write fails, it can also ensure that redis continues to accept new write requests.
rdb-del-sync-files no
Deleting RDB files used in replication without persistence is enabled. By default no, this option is disabled.
rdbchecksum yes
Default yes
After storing the snapshot, you can also let redis use the CRC64 algorithm for data verification, but doing so will increase performance consumption by about 10%. If you want to get the maximum performance improvement, you can turn off this function.

AOF (Append Only File) persistence

Record each write operation in the form of a log, and record all write instructions executed by Redis (read operations are not recorded). Only files can be appended, but files cannot be rewritten. At the beginning of redis startup The file will be read to reconstruct the data. In other words, when redis is restarted, the write instructions will be executed from front to back according to the contents of the log file to restore the completed data.

By default, redis does not enable AOF, and the configuration is enabled: appendonly yes.

appendfsync file sync policy **
appendfsync Always: write back synchronously. After each write command is executed, the log will be synchronized and written back to the disk immediately**. High reliability, almost no data loss
appendfsync everysec: Write back every second. After each write command is executed, the log is first written to the memory buffer of the AOF file, and the contents of the buffer are written to the disk every second. Better performance
appendfsync no: writeback controlled by the operating system. After each write command is executed, the log is first written to the memory buffer of the AOF file. The operating system decides when to write the buffer content back to the disk. . Good performance

# Whether to enable aof
appendonly yes

# file name
appendfilename "appendonly.aof"

# Synchronously
appendfsync everysec

# Whether to synchronize during aof rewriting
no-appendfsync-on-rewrite no

# Rewrite trigger configuration
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# What to do if there is an error when loading aof
aof-load-truncated yes

#File rewrite strategy
aof-rewrite-incremental-fsync yes