Redis持久化配置

Redis的持久化有2种方式1快照2是日志

• 持久化: 即把数据存储于断电后不会丢失的设备中,通常是硬盘.

常见的持久化方式:

1. 主从:通过从服务器保存和持久化,如mongoDB的replication sets配置
2. 日志:操作生成相关日志,并通过日志来恢复数据couchDB对于数据内容,不修改,只追加,则文件本身就是日志,不会丢失数据.

1、Rdb快照

rdb的工作原理:    实际上就是内存快照的形式。

每隔N分钟或N次写操作后, 从内存dump数据形成rdb文件,压缩放在备份目录
注:红色部分可通过参数来配置

配置选项

save 900 1 // 900内,有1条写入,则产生快照
save 300 1000 // 如果300秒内有1000次写入,则产生快照
save 60 10000 // 如果60秒内有10000次写入,则产生快照

(这3个选项都屏蔽,则rdb禁用)    理解的话可以倒着向上看

stop-writes-on-bgsave-error yes // 后台备份进程出错时,主进程停不停止写入?  主进程不停止 容易造成数据不一致
rdbcompression yes // 导出的rdb文件是否压缩    如果rdb的大小很大的话建议这么做
Rdbchecksum yes // 导入rbd恢复时数据时,要不要检验rdb的完整性 验证版本是不是一致   
dbfilename dump.rdb //导出来的rdb文件名
dir ./ //rdb的放置路径

在2个保存点之间,断电,将会丢失1-N分钟的数据 ,对于商业上面的应用，丢失的数据就是个disaster。     但是这个方式下 数据恢复的比较快。   建议使用 rdb 跟 aof 配合使用。
出于对持久化的更精细要求,redis增添了aof方式 append only file

2、Aof

1:每个命令重写一次aof?     是  当然还有重写规则    aof文件过大的话 ，触发重写，gbwrite 。
2:某key操作100次,产生100行记录,aof文件会很大,怎么解决?  

配置  aof 主要记录执行的命令     aof文件的路径直接修改     跟 rdb不一样 rdb 修改有单独的配置选项：dir选项。

appendonly no // 是否打开aof日志功能     aof跟  rdb都打开的情况下 
appendfsync always // 每1个命令,都立即同步到aof. 安全,速度慢
appendfsync everysec // 折衷方案,每秒写1次
appendfsync no // 写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof. 同步频率低,速度快,

no-appendfsync-on-rewrite yes: // 正在导出rdb快照的过程中,要不要停止同步aof
auto-aof-rewrite-percentage 100 //aof文件大小比起上次重写时的大小,增长率100%时,重写    缺点  刚开始的时候重复重写多次
auto-aof-rewrite-min-size 64mb //aof文件,至少超过64M时,重写

配置好以上文件之后测试使用 redis-benchmark  -n  10000 表示 执行请求10000次，执行ls   发现出现 rdb 跟 aof文件。

appendonly.aof     dump.rdb      

3、注意的事项

注: 在dump rdb过程中,aof如果停止同步,会不会丢失?

答: 不会,所有的操作缓存在内存的队列里, dump完成后,统一操作.

注: aof重写是指什么?

答: aof重写是指把内存中的数据,逆化成命令,写入到.aof日志里.

以解决aof日志过大的问题.

问: 如果rdb文件,和aof文件都存在,优先用谁来恢复数据?

答: aof 

问: 2种是否可以同时用?

答: 可以,而且推荐这么做

问: 恢复时rdb和aof哪个恢复的快

答: rdb快,因为其是数据的内存映射,直接载入到内存,而aof是命令,需要逐条执行