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

Redis data persistence

Redis provides the ability to automatically persist data to the hard disk on a regular basis, including RDB,AOF, both of which have their own advantages and disadvantages and can be used together to ensure the stability of the data.

Must data persistence be used?

The Redis data persistence mechanism can be turned off. If you use the Redis service as a caching service, and all the data stored in Redis is not the body of the data but just a synchronized backup, you can turn off the data persistence mechanism of Redis.

In general, however, it is recommended that you at least turn on data persistence in RDB mode, because:

Persistence in RDB mode hardly consumes the performance of Redis itself. In RDB persistence, the only thing the Redis main process needs to do is to fork a child process, and all the persistence work is done by the child process.

Redis can automatically recover the data recorded in the last RDB snapshot when it is rebooted after the crash is dropped for whatever reason. This eliminates the need to manually synchronize data from other data sources, such as DB, and is faster than any other data recovery method.

Now that the hard drive is so big, there is really no shortage of that space.

RDB

With RDB persistence, Redis periodically saves a snapshot of the data to a rbd file, and automatically loads the rdb file at startup to restore the previously saved data. You can configure when Redis saves snapshots in the configuration file:

Save [seconds] [changes]

If there are [changes] times of data modification within [seconds] seconds, a RDB snapshot is saved, for example

Save 60 100

Redis is asked to check for data changes every 60 seconds, and if there are 100 or more data changes, RDB snapshots are saved.

Multiple save instructions can be configured to have Redis execute a multi-level snapshot save policy.

Redis enables RDB snapshot by default, and the default RDB policy is as follows:

Save 900 1save 300 10save 60 10000

RDB snapshot save can also be triggered manually through the BGSAVE command.

Advantages of RDB:

Has the least impact on performance. As mentioned earlier, Redis will fork child processes when saving RDB snapshots, which hardly affects the efficiency of Redis in processing client requests.

Each snapshot generates a complete data snapshot file, so you can save snapshots at multiple points in time by other means (such as backing up snapshots at 0 o'clock every day to other storage media) as a very reliable means of disaster recovery.

Using RDB files for data recovery is much faster than using AOF.

Disadvantages of RDB:

Snapshots are generated periodically, so some of the data is more or less lost during Redis crash.

If the dataset is very large and the CPU is not strong enough (such as a single-core CPU), the Redis may take a relatively long time (up to 1 second) to fork the child process, affecting client requests during this period.

AOF

With AOF persistence, Redis records every write request in a log file. When Redis restarts, all writes recorded in the AOF file are executed in order to ensure that the data is up to date.

AOF is disabled by default. To enable it, configure as follows:

Appendonly yes

AOF provides three fsync configurations, always/everysec/no, which is specified through the configuration item [appendfsync]:

Appendfsync no: leave the timing of the flush file to OS without fsync, which is the fastest.

Appendfsync always: perform a fsync operation every time a log is written, with the highest data security but the slowest speed

Appendfsync everysec: a compromise, leaving the background thread to fsync once per second

As AOF keeps logging write operations, there must be some useless logs, such as the command SET key1 "abc" at some point in time and SET key1 "bcd" at some point in time, then the first command is obviously useless. A large number of useless logs can make AOF files too large and take too long to recover data.

So Redis provides the AOF rewrite function to rewrite AOF files, keeping only the minimum set of write operations that can restore data to the latest state.

AOF rewrite can be triggered by the BGREWRITEAOF command, or you can configure Redis to do it automatically on a regular basis:

Auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb

The meaning of the configuration of the above two lines is that Redis records the size of the AOF log after the completion of the rewrite each time it is AOF rewrite, and when the size of the AOF log increases by 100%, AOF rewrite is performed automatically. At the same time, if the size of the growth does not reach 64mb, then rewrite will not occur.

Advantages of AOF:

The safest, any written data will not be lost when appendfsync always is enabled, and only 1 second of data will be lost when appendfsync everysec is enabled.

AOF files will not be damaged in the event of problems such as power outages, and even if a log is only half written, it can be easily repaired using the redis-check-aof tool.

The AOF file is easy to read and can be modified. After some erroneous data cleaning operations, as long as the AOF file does not have rewrite, you can back up the AOF file, delete the wrong command, and then restore the data.

Disadvantages of AOF:

AOF files are usually larger than RDB files

Performance consumption is higher than RDB

Data recovery is slower than RDB

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.