Redis persistence (RDB + AOF)

Redis persistence

• RDB snapshot storage
• AOF only append files

1.1 RDB snapshot storage

• The all data in memory the complete saved to the hard disk
• mechanism
  • fork a child process , specifically for data persistence, save all data into a single memory rdb file (the default is dump.rdb)
  • Redis after the restart, it will load the data rdb file into memory
• Trigger
  • Configuration settings automatically persistence strategy
  • The SAVE | bgsave | SHUTDOWN (set automatic persistence strategy when the premise)
• Related

save 60 1000  # 多久执行一次自动快照操作, 60秒内如果更新了1000次, 则持久化一次
stop-write-on-bgsave-error no  # 创建快照失败后, 是否继续执行写命令
rdbcompression yes  # 是否对快照文件进行压缩
dbfilename dump.rdb  # 如何命名快照文件
dir ./  # 快照文件保存的位置

save   # 关闭RDB机制

• Advantages and disadvantages
  • advantage
    • Facilitate data backup : saving due to a separate file , the data backup easily (can use timed task, the timing to send the file to the backup data center)
    • Copy On Write : child process to complete persistence operations alone, the parent process does not participate IO operations, maximize performance redis
    • When large amounts of data recovery, is faster than AOF
  • Shortcoming
    • Real-time data is not saved , if redis unexpectedly stops working (such as power failure, etc.), you may lose data over time
    • When large volumes of data, fork process will be slower, redis slow response times when persistence

1.2 AOF only append files

• Append-only file only append files
  • Only added , but not all rewritten
  • Append command , rather than data
• mechanism
  • The main thread will write commands added to the aof_buf (buffer), depending on the use of different strategies, the child thread write command buffer to the aof file (do not use child process)
  • When redis restart, it will re-execute the aof file command to recover data
    • If both the RDB , the priority use of AOF
• File Repair
  • If you use the AOF error (disk is full / write process downtime, etc.), then redis reject this AOF file restart
  • Repair steps
    • First of all backup files AOF
    • Use reids-checkout-aof tool to repair (usually at the end of the delete command can not be recovered)
    • Redis restart the server, back-end loaded automatically repair AOF files, data recovery

$ redis-checkout-aof -fix
# 可选操作: 使用 diff -u  对比修复后的 AOF 文件和原始 AOF 文件的备份, 查看两个问及爱你之间的不同之处

• Overwriting files / compression
  • AOF provides a rewrite / compression schemes (optimization command) to avoid AOF file is too large
  • fork child process to complete AOF rewrite
• Related

 appendonly no  # 是否开启AOF机制
 appendfsync everysec  # 多久将写入的内容同步到硬盘  每秒一次
 no-appendfsync-rewrite no  # 重写aof文件时是否执行同步操作
 auto-aof-rewrite-percentage 100  # 多久执行一次aof重写, 当aof文件的体积比上一次重写后的aof文件大了一倍时
 auto-aof-rewrite-min-size 64mb  # 多久执行一次aof重写, 当aof文件体积大于64mb时

appendfilename appendonly.aof  # aof文件名
dir ./  # aof文件保存的位置(和rdb文件共享改配置)

• Advantages and disadvantages
  • advantage
    • More reliable default once synchronization operations per second, a maximum of one second lost data
    • Offers three strategies, you can not synchronize / sync each write
  • Can file rewritten to avoid AOF file is too large
• Shortcoming
  • The same data set, file AOF of RDB than bulky, slow recovery
  • Unless it is not synchronized, otherwise than in the general RDB slow

1.3 How to choose

• For frequent updates, consistency requirements are not very high data can choose to use persistent storage redis
• RDB or AOF
  • High database security requirements, are open
  • Data can accept short-term loss, but with RDB
  • Even with AOF of , preferably also opens a RDB , as the speed of recovery and facilitate backup block, bug less