redis-002备份

阅读量: zyh 2017-12-22 11:46:44
Categories: > Tags:

前言

本文主要记录 redis 的两种数据磁盘固化方式。
涉及到相关参数,简单的命令操作等。

rdb

通过save或者bgsave存储某一时刻redis数据。rdb持久化是默认方式。

特点:

  • 小幅度丢失数据(取决于save或者bgsave命令的执行周期)。
    • save命令会阻塞其它客户端访问,基本不会用。
    • bgsave会fork一个子进程来处理,子进程不会阻塞,不过会占用额外的内存。✨fork子进程这个操作会阻塞,一般这个操作很快。
  • 恢复速度快,因为它就是redis内存数据的快照,只需要将rdb文件直接加到内存里。
# 压缩rdb文件
rdbcompression yes
# rdb 文件名称
dbfilename redis-6379.rdb
# rdb文件保存目录
dir /redis/data/
# 900s内至少达到一条写命令
save 900 1
# 300s内至少达至10条写命令
save 300 10
# 60s内至少达到10000条写命令
save 60 10000
*/10 * * * * root /export/redis/bin/redis-cli -h 127.0.0.1 bgsave >> /export/redis/bgsave.log 2>&1  

bgsave 因需要fork子进程,所以需要额外预留空闲的物理内存,在overcommit_memory=1开启的情况下,预留内存大小 > 周期变化数据大小

aof

记录的是redis每一次的写入操作记录

特点:

  • 恢复速度慢,因为aof记录的不是内存数据快照,而是执行过的命令,恢复的时候需要从新执行。
  • 丢失数据小。默认是1秒同步一次执行命令到aof文件内。
# 开启aof机制
appendonly yes
# aof文件名
appendfilename "appendonly.aof"
# 写入策略
## always 表示每个写操作在写入aof_buffer后,都立即执行fsync同步到磁盘。
## everysec 表示每个写操作在写入aof_buffer后,每秒执行一次fsync同步到磁盘。这是默认值
## no 表示每个写操作在写入aof_buffer后,由操作系统自身策略执行一次fsync同步到磁盘。(一般默认操作系统是30秒)。
appendfsync everysec
# 重写(压缩)AOF文件的时候不立即执行fsync
## no 意思就是压缩整合aof文件后立即调用fsync。
## yes 意思就是重写aof文件后,将其放置缓冲区。缓解io压力,但可能会因为down机丢数据。
no-appendfsync-on-rewrite yes
# 保存目录
dir /redis/data/
*/10 * * * * root /export/redis/bin/redis-cli -h 127.0.0.1 bgrewriteaof >> /export/redis/bgrewriteaof.log 2>&1
cp aof aof.bak
redis-check-aof -fix file.aof

AOF重写

AOF重写意思:将AOF文件中冗余的命令删除,例如多个set key1指令,只需要保留最后一个set key1指令即可。

AOF重写原理:AOF 重写和 RDB 创建快照一样,都巧妙地利用了写时复制机制

✨AOF重写和bgsave不会同时进行。如果bgsave的过程中,发起aof重写,则这个操作是异步。redis会立即返回OK,并在bgsave执行完后执行。

💥 rdb的save操作和aof的文件重写,都会消耗磁盘性能。

结论

官方建议是两者都开启,具体根据业务情况确定是否需要,但是不管是哪一种,都可以在人工计划任务之后,复刻一份备份文件到云端对象存储中。