AOF (Append Only File)

Record all the commands, similar to the histrory operation, the file will be executed during recovery

Introduction to the

  • Each write operation is recorded in the form of a log, recording all instructions executed by Redis (read operations are not recorded).

  • Only files can be appended but files can not be overwritten. When Redis starts up, it will read the file and rebuild the data. In other words, when Redis restarts, it will execute the write command from front to back according to the contents of the log file.

Configuration AOF

Restart the RedisTo check whether the directory has appendone.aof

Test AOF

  • Modify the AOF file

  • Restarting Redis failed. Procedure

  • Repair (sudo redis-check-aof --fix appendonly.aof)

Pay attention to

Appendone.aof will not be fixed if it is removed

Rewrite rules

  • By default, aOF allows files to be appended indefinitely, making them bigger and bigger

  • If the aOF file is larger than 64MB, Redis will fork a new program to rewrite the file.

Advantages and disadvantages

Advantages:

  • Every change is synchronized and the file integrity is better
  • If you synchronize once per second, you may lose one second of data
  • Never synchronized for maximum efficiency

Disadvantages:

  • Aof is much larger than RDB relative to data files, and repairs are slower than RDB!
  • AOF is also slower than RDB, so our redis configuration is RDB persistence

Expansion of:

  • RDB persistence allows you to take snapshots of your data at specified intervals
  • When the server is restarted, it will execute these commands again to restore the original data. AOF command stores each write operation to the end of the file using Redis protocol. Redis can also rewrite the AOF file in the background, so that the size of the AOF file is not too large.
  • If you only want your data to exist while the server is executing, you can also do without any persistence
  • Enable both persistence methods

1. In this case, when Redis restarts, AOF files will be loaded first to recover the original data, because in general, AOF files store a more complete data set than RDB files. 2, RDB data is not real-time, when using both servers, the server will only find AOF files, so should only use AOF? The author advises against this, as RDB is better for backing up databases (AOF is constantly changing and not easy to back up), fast restart, and no potential AOF bugs, leaving the work as a just in case means.

Efficiency of the suggested

  • Since RDB files are only used for backup purposes, it is recommended to persist RDB files only on the Slave(Slave disk) and backup them only once every 15 minutes. Only save 9001 is retained.
  • If you Enable AOF, you will lose data for no more than two seconds in the worst case. If you Enable AOF, you will lose data for no more than two seconds. If you Enable AOF, you will lose data for no more than two seconds. The second is the end of AOF rewriting. The blockage caused by writing new material into new files is almost inevitable. As long as hard drives permit, the frequency of AOF rewrite should be reduced as much as possible. The base size default of AOF rewrite (64M) is too small and can be set to more than 5G.
  • If AOF is not enabled, high availability can be achieved by using master-slave Repllcation (Master Slave Repllcation), saving a lot of I/O and reducing the amount of system volatility that would result from rewriting. The price is that if the Master/Slave goes down at the same time, the data will be lost for more than ten minutes. The startup command code also needs to compare the RDB files in the two Master/Slave and load the newer one.