Redis persistence mechanism comparison

RDB
1. Take snapshots of the data set at specific time intervals
2. Each persistence is to write the full amount of data, not incremental
3. Write the data to a temporary file and then replace the original rdb file
advantages
: 1. RDB is a separate file, which is convenient for backup and disaster recovery
2. The data writing mode is for the parent process to fork a child process to perform disk io operations, while the parent process does not need to participate in io operations
3. In the case of large data, the startup speed is faster than AOF
Disadvantages
: 1. In this mode, if redis crashes or is powered off, there may be data loss; because RDB is based on a fixed strategy (such as flushing once every 10 seconds or within 5 minutes) If 100 pieces of data are written and then flushed to disk, etc.) for persistence, the data for a certain period of time may be lost in the event of a power failure or service crash
2. RDB requires fork child processes to do disks when the process is persistent. Operation, when the data set is relatively large, the fork operation is very time-consuming, and the server cannot serve the client during the fork process; although AOF also needs fork, we can set how often to rewrite the log

AOF
1. The server writes for each Operation record log;
2. If the service is restarted, replay the recorded log to reconstruct the entire data set.
3. The log is recorded using redis's own protocol, which is recorded in the append mode.
4. If the log is too large, redis can rewrite the log file in the background
Advantages :
1. Various fsync strategies can be set: never flush data, synchronize once per second (default), synchronize each time query, the last second of data may be lost when using the default strategy; when the configuration never flushes data, the main thread When the current process does not synchronize the data to the file as much as possible when flushing the data, a background sub-thread will be started to synchronize the data to the file in the default strategy.
2. The log file is in append mode, which does not involve file pointer search and file pointer search after the breakpoint. Data loss problem; even if the last log file is only half written for some reasons (such as disk full, etc.), it can be fixed by the redis-check-aof tool
3. When the log file is too large, redis will automatically Rewrite the log file ( the new file only retains the commands needed to create the current data set ); in the process of rewriting, it will also write to the old log file. Once the new file is processed, redis will switch to the new one
4. The content of the log file is simple and clear, which is convenient for manual intervention . For example, if we call flushall to refresh and save all data failure, if no other commands are written to the log file at this time, we can stop the server, delete the last error in the log, and then restart to restore the data
Disadvantages
: 1. Under the same data set , AOF mode corresponding file is usually larger than RDB corresponding file
2.AOF is slower than RDB mode under some strategies. For example, when fsync is set to once per second, the performance is still high; when fsync is disabled, the performance is close to
3 with RDB. Some commands may have problems under AOF, such as BRPOPLPUSH command replay fails when reloading under AOF

Description :
RDB and AOF persistence mechanisms can be used at the same time in the same instance; however, the AOF mechanism is used to rebuild the dataset when the service is started (because AOF preserves the integrity of the data to the greatest extent)

Choose:
1. If you want to strictly guarantee the integrity of the data property, then RDB and AOF are used at the same time
2. If a small amount of data loss can be tolerated, use RDB
3. It is not recommended to use AOF alone (because RDB backup is more convenient and restart is relatively fast; AOF may have bugs)

Reference:
https://redis.io/topics/persistence