Let's talk about the persistence mechanism of Redis. Should we use RDB or AOF?

This article will take you to understand the persistence mechanism of Redis (RDB and AOF), and talk about whether to use RDB or AOF? I hope to be helpful!

RDB

#1. What is RDB

#RDB: Every once in a while, the The data is written to a temporary file on the disk as a snapshot, and the snapshot file is read into the memory during recovery. If it crashes and restarts, the data in the memory will definitely be gone. Then it will be restored after starting redis again. [Related recommendations: Redis video tutorial]

2. Backup and recovery

Memory backup--> Disk temporary file
Temporary File --> Restore to memory

3. RDB advantages and disadvantages

• Advantages

  • Back up every once in a while, Full backup

  • Disaster recovery is simple and can be transmitted remotely

  • When the child process is backed up, the main process will not have any io operations (no (write, modify or delete) to ensure the integrity of the backup data

  • Compared with AOF, when there are larger files, you can quickly restart and restore

• Disadvantages

  • When a failure occurs, the last backup data may be lost

  • The memory ratio occupied by the child process It will be exactly the same as the parent process. If it will cause CPU burden

  • Since scheduled full backup is a heavyweight operation, real-time backup cannot be processed.

4. RDB configuration

• The saving location can be set in redis.conf Definition:
  /user/local/redis/working/dump.rdb

• Saving mechanism:

save 900 1
save 300 10
save 60 10000
save 10 3

* 如果1个缓存更新，则15分钟后备份
* 如果10个缓存更新，则5分钟后备份
* 如果10000个缓存更新，则1分钟后备份

• stop-writes-on-bgsave-error

  • yes: If an error occurs during the save process, stop the write operation
  • no: May cause data inconsistency

• rdbcompression

  • yes: Turn on rdb compression mode
  • no: Turn it off, which will save CPU consumption, but the file will be larger, the same reason as nginx

• rdbchecksum

  • yes: Use CRC64 algorithm verification to perform data verification on rdb, with a 10% performance loss
  • no: No verification Verification

Summary

RDB is suitable for the recovery of large amounts of data, but the integrity and consistency of the data may be insufficient.

AOF

AOF features

• Record write operations requested by users in the form of logs. Read operations are not logged, as only write operations are stored.

• The file is appended rather than modified.

• Redis' aof recovery is actually to read and write the appended file from the beginning to the end.

Advantages

• AOF is more durable and can be backed up in seconds. If a problem occurs, it will only Losing the last second of data greatly increases reliability and data integrity. So AOF can be backed up once per second, using fsync operation.

• Append in the form of log log. If the disk is full, the redis-check-aof tool will be executed.

• When the data is too large, Redis can automatically rewrite aof in the background. When redis continues to append logs to old files, rewriting is also very safe and will not affect the client's read and write operations.

• All write operations contained in the AOF log will make it easier to parse and recover redis.

Disadvantages

• The same data, the same data, AOF is larger than RDB

• For different synchronization mechanisms, AOF will be slower than RDB, because AOF will back up and do write operations every second, which is slightly lower than RDB. There is nothing wrong with backing up fsync every second, but if the client performs a backup fsync every time it writes, the performance of redis will decrease.

• A bug has occurred in AOF, that is, the data is incomplete during data recovery. This makes AOF more fragile and prone to bugs, because AOF is not as simple as RDB, but in order to prevent bugs generated, AOF will not be reconstructed based on the old instructions, but will be reconstructed based on the data instructions existing in the cache at that time, which makes it more robust and reliable.

AOF configuration

`# AOF 默认关闭，yes可以开启
appendonly no

# AOF 的文件名
appendfilename "appendonly.aof"

# no：不同步
# everysec：每秒备份，推荐使用
# always：每次操作都会备份，安全并且数据完整，但是慢性能差
appendfsync everysec

# 重写的时候是否要同步，no可以保证数据安全
no-appendfsync-on-rewrite no

# 重写机制：避免文件越来越大，自动优化压缩指令，会fork一个新的进程去完成重写动作，新进程里的内存数据会被重写，此时旧的aof文件不会被读取使用，类似rdb
# 当前AOF文件的大小是上次AOF大小的100% 并且文件体积达到64m，满足两者则触发重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb`

Should we use RDB or AOF?

• If you can accept cache loss for a period of time, you can use RDB

• If you are more careful about real-time data , then use AOF

• Use RDB and AOF together for persistence. RDB is used as cold backup, which can restore different versions at different times, and AOF is used as hot backup to ensure that data is only lost for 1 second. When the AOF is damaged and unavailable, then use RDB to restore it, so that the two are combined. That is to say, Redis recovery will load AOF first, and if there is a problem with AOF, it will load RDB again, thus achieving the purpose of hot and cold backup. .

For more programming-related knowledge, please visit: Introduction to Programming! !

The above is the detailed content of Let's talk about the persistence mechanism of Redis. Should we use RDB or AOF?. For more information, please follow other related articles on the PHP Chinese website!