Table of contents
Interpretation of configuration position parameters
Recovery of RDBRDB persistent files
Recovery failure handling method
Redis is an in-memory database. When the redis server is restarted and the computer is restarted, the data will be lost. We can persist the data in the redis memory to a file on the hard disk.
Persistence methods are:
- RDB: regularly save data in the hard disk (dump.rdb) (default)
- AOF: Command to save all operations
What is RDB
Write the snapshot of the data set in the memory to the disk within the specified time interval, which is the Snapshot snapshot in jargon. When it is restored, it reads the snapshot file directly into the memory.
Redis will create (fork) a child process separately for persistence, and will first write the data into a temporary file, and after the persistence process is over, then use this temporary file to replace the last persisted file. During the whole process, the main process does not perform any IO operations. This ensures extremely high performance. If large-scale data recovery is required and the integrity of data recovery is not very sensitive, the RDB method is more efficient than the AOF method.
The disadvantage of RDB is that the data after the last persistence may be lost. Our default is RDB, under normal circumstances do not need to modify this configuration
The file saved by rdb is dump.rdb, which can be configured in the snapshot in our configuration file
Interpretation of configuration position parameters
The save path of the rdb file can also be modified. The default is the directory where the command line is located when Redis starts
dir "/myredis/"By default, at least 10,000 key changes occur within 1 minute, or at least 100 key changes occur within 15 minutes, or at least 1 key change occurs within 1 hour
# 周期性执行条件的设置格式为
save <seconds> <changes>
# 默认的设置为：
# 如果900秒内有1条Key信息发生变化，则进行快照
save 900 1
# 如果300秒内有10条Key信息发生变化，则进行快照
save 300 10
# 如果60秒内有10000条Key信息发生变化，则进行快照
save 60 10000how to use
automatic trigger
- Configure save mn in redis.conf, that is, when there are n times of modification within m seconds, bgsave is automatically triggered to generate rdb files
- During master-slave replication, when the slave node wants to perform full replication from the master node, the bgsave operation will also be triggered, and the snapshot at that time will be generated and sent to the slave node
- The bgsave operation will also be triggered when the debug reload command is executed to reload redis
- By default, when the shutdown command is executed, if aof persistence is not enabled, the bgsave operation will also be triggered
Executing the flushall command will also generate a dump.rdb file, but it is empty and meaningless, so in general, if you want to back up, before executing the flushall command, we can first backup dump.rdb to other places.
manual trigger
The redis client executes the bgsave command or automatically triggers the bgsave command
| Way | save command | bgsave command |
|---|---|---|
| read and write | Synchronize | asynchronous |
| blocking client commands | yes | no |
| additional memory consumption | no | yes |
| start new process | no | yes |
save
The save command performs a synchronous save operation, saving all data snapshots (snapshots) of the current Redis instance to the hard disk in the form of RDB files. It is rare to use commands directly in the production environment SAVE, because it will block all client requests, and BGSAVEcommands can be used instead. If BGSAVEan error occurs in the child process of saving data in the command, SAVEsaving the latest data with the command is the last resort.
redis> SAVE
OKbgsave
The Bgsave command is used to asynchronously save the data of the current database to disk in the background. The BGSAVE command returns OK immediately after execution, and then Redis forks a new child process. The original Redis process (parent process) continues to process client requests, and the child process is responsible for saving data to disk and then exiting.
redis> BGSAVE
Background saving startedReturn value: feedback information.
Recovery of RDB RDB persistent files
normal recovery
- Copy the backed up RDB file to the working directory of Redis.
- Set the dbfilename and dir parameters in the Redis configuration file, which are the RDB file name and path respectively.
- Just start the Redis server.
See where it needs to exist:
127.0.0.1:6379> config get dir
1) "dir"
2) "/data"
Recovery failure handling method
If the RDB file is damaged or incomplete, you can try to use the redis-check-rdb tool that comes with Redis to check the validity of the file and try to repair the errors in the file.
redis-check-dump FILENAME
Advantages of RDB
- RDB is a very compact single-file point-in-time representation of Redis data. RDB files are great for backups. For example, you might want to archive RDB files every 24 hours and keep RDB snapshots every day for 30 days. This allows you to easily restore different versions of your dataset in the event of a disaster.
- RDB is great for disaster recovery as a single compact file that can be transferred to a remote data center or to Amazon S3 (possibly encrypted).
- RDB maximizes Redis performance because the only work a Redis parent process needs to do in order to persist is to fork a child process that will do all the rest. The parent process never does disk I/O or similar.
- Compared to AOF, RDB allows for faster restarts of large datasets.
Disadvantages of RDBs
- RDB is not good if you need to minimize the chance of data loss if Redis stops working (eg after a power outage) . You can configure different savepoints where the RDB is generated (for example, you can have multiple savepoints after at least 100 minutes and <> writes against the dataset ) . However, you'll typically be creating RDB snapshots every five minutes or more, so if for any reason Redis stops working without shutting down properly, you should be prepared to lose the last few minutes of your data.
- RDBs often need to fork() to persist on disk using subprocesses. If the dataset is large, fork() can be time-consuming, and if the dataset is very large and the CPU performance is not very good, it may cause Redis to stop serving clients for a few milliseconds or even a second. AOF also requires fork(), but less frequently, and you can tune how often the log is rewritten without sacrificing durability.