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

1. RDB

1.1 introduction to RDB

RDB: writes a snapshot of a dataset in memory to disk, or Snapshot snapshot in jargon, within a specified time interval. When it is restored, it reads the snapshot file directly into memory.

How it works: at regular intervals, the data in memory is saved to a specified file on the hard disk.

RDB is enabled by default!

Redis will create (fork) a child process for persistence. It will first write the data to a temporary file. After the persistence process is over, the temporary file will be used to replace the last persisted file. Throughout the process, the main process does not perform any IO operations, which ensures extremely high performance. If large-scale data recovery is required and is not very sensitive to the integrity of data recovery, then RDB is more efficient than AOF.

The disadvantage of RDB is that the data may be lost after the last persistence.

1.2 RDB Save Policy

Save 9001,900 seconds if the value of at least one key changes, save

If the value of at least 10 key changes within 10300 seconds of save 300s, save

Save 60 10000 if the value of at least 10000 key changes within 60 seconds, save

Save "" is to disable RDB mode.

1.3 RDB Common attribute configuration

1.4 RDB data loss

During the interval between the two saves, the server goes down, or a power outage occurs.

1.5 RDB trigger

① is based on auto-save strategy

② executes the save, or bgsave command! When executed, it is in a blocking state.

When ③ executes the flushdb command, it also produces dump.rdb, but it is empty and meaningless.

④ also actively backs up data when executing the shutdown command

2. AOF

2.1 introduction to AOF

AOF records each write operation in the form of a log. Every time the data is modified, the commands to create and modify the data are saved to the specified file. When Redis restarts, read this file and re-execute the commands to create and modify data to restore the data. This is not enabled by default. You need to manually open the save path of the AOF file, which is the same as the path of RDB. When AOF saves commands, it only saves commands that modify data, that is, write operations! When the storage of RDB and AOF is inconsistent, restore it according to AOF. Because AOF is a supplement to RDB. Backup cycles are shorter and more reliable.

2.2 AOF Save Policy

Appendfsync always: save operations are performed every time a new command is generated to modify the data; inefficient, but safe!

Appendfsync everysec: a save operation is performed every second. If a power outage occurs when the operation is not saved within the current second, it will still result in some data loss (that is, 1 second of data).

Appendfsync no: never save, leave the data to the operating system for processing. Faster and less secure options.

The recommended (and default) measure is fsync per second, which is a fsync strategy that combines speed and security.

2.3 AOF Common Properties

2.4 repair of AOF files

If a residual command appears in the AOF file, the server cannot be restarted. At this point, you need to use the redis-check-aof tool to fix it!

Command: redis-check-aof-- fix file

Summary

The above is the whole content of this article. I hope the content of this article has a certain reference and learning value for everyone's study or work. Thank you for your support. If you want to know more about it, please see the relevant links below.

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.