Persisting the SNAPSHOT RDB


By storing all data at a point in time on hard disk, snapshots can be copied to other servers to create replicas of servers with the same data





Features:


1. Snapshots are binary files in nature.


2. For full backup.


3, not applicable to real-time, persistent backup;


4, the recovery speed is fast, higher than AOF


5. Data may be lost after the last snapshot is created


6. A large amount of data and a long time to save snapshots.





AOF persistence adds write commands to the end of an AOF File (Append Only File)





When adding a write command to an AOF file, there are the following synchronization options:


Always: Each write command is synchronized, severely reducing server performance.


Everysec: Synchronizes once per second, which is appropriate to ensure that only one second of data will be lost when the system crashes, and Redis synchronizes once per second with almost no impact on server performance;


No: Let the operating system decide when to synchronize, which improves performance and increases the amount of data lost during a crash


When a file is written to the hard disk, the data is first stored in the buffer, and the operating system determines when the data is written. You can call file.flush() to request that the data be synchronized to the hard disk as soon as possible





Features:


1. Log write commands


2. It applies to real-time persistence of data





Snapshot trigger time:


RDB(manually triggered, two methods save, bgSave);


AOF manually triggered: The bgrewriteaof command is invoked


AOF automatic trigger: Trigger according to the file volume, file space design size





Various persistence application scenarios:


RDB: does not consider a small amount of data loss; Large file data, Dr


AOF: real-time backup is required