Redis 本身支持持久化,通过在一定时间间隔或触发操作,将内存中的数据同步到磁盘来保证持久化。Redis 支持两种持久化方式,一种是 Snapshotting(快照),保存为dump.rdb文件,也是默认方式,另一种是 Append-only file(缩写aof)的方式,保存为 .aof 文件。
Snapshot 快照 通过save或者bgsave命令通知redis做一次快照持久化。save操作是在主线程中保存快照的,由于redis是用一个主线程来处理所有客户端的请求,这种方式会阻塞所有客户端请求。所以不推荐使用。另一点需要注意的是,每次快照持久化都是将内存数据完整写入到磁盘一次,并不是增量的只同步增量数据。如果数据量大的话,写操作会比较多,必然会引起大量的磁盘IO操作,可能会严重影响性能。
在默认的快照 rdb保存方式中,redis.conf 里面的配置如下
1
2
3
|
save 900 1
#900秒内如果超过1 个key 被修改,则发起快照保存
save 300 10
#300秒内容如超过10个key 被修改,则发起快照保存
save 60 10000
|
如果我们需要关闭快照,只需要将这几行注释了,然后重启 redis 即可。
如果是正在运行的实例,可以使用 redis-cli的命令
1
2
3
4
|
# 查看当前配置
config get save
# 关闭快照
config set save
""
|
来在线更新配置,输出OK表示设置成功。
AOF 比快照方式有更好的持久化性,是由于在使用aof 持久化方式时, redis 会将每一个收到的写
命令都通过write函数追加到文件中(默认是appendonly.aof) 。当redis 重启时会通过重新执行文件中
保存的写命令来在内存中重建整个数据库的内容
默认配置如下:
1
2
3
4
|
appendonly
yes
//
启用日志追加持久化方式
#appendfsync always //每次收到写命令就立即强制写入磁盘,最慢的,但是保证完全的持久化,不推荐使用
appendfsync everysec
//
每秒钟强制写入磁盘一次,在性能和持久化方面做了很好的折中,推荐
#appendfsync no //完全依赖操作系统,性能最好,持久化没保证
|
我们需要更新配置文件为:
1
|
appendfsync no
|
在线更新配置使用
1
2
3
4
|
# 查看当前配置
config get appendfsync
# 关闭快照
config set appendfsync
no
|
通过这两个配置,redis就可以完全在内存运行。
如果想手动进行持久化,可以使用Redis的 bgsave 和 bgrewriteaof 来手动进行持久化。
redis数据持久化与恢复
执行指令bgsave 可触发rdb存盘,bgrewriteaof可触发aof重写。
前提:
实际上,当Redis服务器挂掉时,重启时将按照以下优先级恢复数据到内存:
1. 如果只配置AOF,重启时加载AOF文件恢复数据;
2. 如果同时 配置了RDB和AOF,启动是只加载AOF文件恢复数据;
3. 如果只配置RDB,启动是将加载dump文件恢复数据。
也就是说,AOF的优先级要高于RDB,这也很好理解,因为AOF本身对数据的完整性保障要高于RDB。
redis数据恢复方式(仅在只开启RDB,后面又想开启AOF文件q情况下才需要按照如下方式):redis命令:keys *,查看当前redis里的所有key
1、停止服务 ps -ef|grep redis,kill xxx
2、修改redis.conf文件,设置为只配置rbd快照恢复(修改配置文件,找到
appendonly
yes,改为no
)
3、拷贝dump文件到配置的dir(配置文件的dir属性)目录,删除目录下的aof文件
4、重启redis,可以看到keys都恢复了,(或先quit,修改conf文件启动aof,再redis-cli)调用bgrewriteaof命令将数据写入aof文件
5、退出可以看到写满数据的aof文件(如果不自定义名称,默认为appendonly.aof)
6、停止redis服务,修改redis.conf文件配置同时启用aof和rdb恢复
7、启动redis服务,然后数据会从刚刚的aof中恢复过来,这样才算完整了
参考:http://heylinux.com/archives/1932.html
http://blog.youkuaiyun.com/wen158809179/articl...ls/8270251
redis命令中文文档:http://redis.cn/commands.html