Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”)或者把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)。
Redis提供两种方式进行持久化:
- RDB持久化:将redis在内存中的数据记录定时dump到磁盘
- AOF持久化:将redis的操作日志以追加的方式写入文件
一、 RDB
在制定的时间间隔内将内存中的数据集快照写入磁盘,实际操作过程是fork一个子进程,先将数据集写入历史文件,写入成功后,再替换之前的文件,用位二进制压缩存储.
1.1 定义RDB文件名
vim /etc/redis/6379.conf
254 dbfilename dump.rdb # dump.rdb为文件名1.2 数据备份
将rdb文件拷贝到备份目录
]# cp /var/lib/redis/6379/dump.rdb /备份路径
1.3 恢复数据
先停止服务器的Redis服务,删除备份服务器的数据库目录下的dump.rdb,将备份文件拷贝到数据库目录下,重新开启Redis服务
]# redis-cli -h 192.168.4.51 6351 shutdown
]# cp /备份目录/备份文件 /var/lib/redis/6379/
]# /etc/init.d/redis_6379 start1.4 优化设置
1.41 数据从内存保存到硬盘的频率
]# vim /etc/redis/6379.conf
219 save 900 1 //900秒且有1个变量改变时保存到硬盘
220 save 300 10 //300秒且有10个变量发生改变时保存到硬盘
221 save 60 10000 //60秒且有10000个变量发生改变时保存到硬盘1.4.2 手动存盘
//命令行操作
192.168.4.52:6352> save //阻塞写存盘,存期间数据库不能进行工作
OK
192.168.4.52:6352> bgsave //不阻塞写存盘.存盘时新建子进程进行存盘操作,父进程依旧执行命令请求
Background saving started1.5 RDB的优缺点
优点
- 使用rdb保存数据,整个redis数据库只包含一个文件,方便数据的备份,迁移和灾备
- 性能最大化,持久化的时候,redis会fork出一个子进程来执行持久化操作,这样不会占用redis服务本身的的IO操作
- 如果数据集很大,RDB的启动效率会高
缺点
- 数据的高可用性能较差.当系统在数据持久化的时候发生宕机现象,那么没来得及写入磁盘的数据都将会丢失.
- RDB采用子进程进行数据的持久化,当数据集较大的时候,服务器可能会停止服务几百毫秒甚至是1秒
二、AOF
以日志的形式记录服务器所处理的每一个写/删除操作,查询操作不会记录,以文本的方式记录,可以打开文件看到详细的操作记录
2.1 开启AOF
同时开启AOF和RDB,AOF的优先级比较高,会优先使用AOF进行数据的持久化
2.1.1 配置文件开启AOF
]# /etc/init.d/redis_6379 stop //或者使用下面的命令
]# redis-cli -h 192.168.4.55 -p 6355 shutdown // 先停止Redis服务
修改配置文件
]# vim +673 /etc/redis/6379.conf //如图所示
注意:直接在配置文件中修改是有问题的
在下次开启Redis服务时,Redis直接读取 appendonly.aof 文件,会丢失原先存储在dump.rdb文件中的数据
2.1.2 命令行开启AOF
192.168.4.52:6352> CONFIG get appendonly //查看是否开启AOF
1) "appendonly"
2) "no"
192.168.4.52:6352> CONFIG set appendonly yes //开启AOF
OK
192.168.4.52:6352> CONFIG get appendonly //查看是否开启成功
1) "appendonly"
2) "yes"
192.168.4.52:6352> CONFIG REWRITE //写进配置文件
OK
2.2 数据恢复
备份数据:备份appendonly.aof文件到其他位置
]# cp /目录/appendonly.aof /备份目录
恢复数据:先关闭备份服务器的Redis服务,删除数据库目录下的appendonly.aof,将备份文件拷贝到数据库目录下,重启备份服务器的Redis服务
]# cp 备份目录/appendonly.aof /数据库目录下
]# /etc/init.d/redis_6379 start2.3 优化配置
2.3.1 定义文件名
appendonly yes //开启AOF
appendfilename "appendonly.aof" //设置AOF文件名2.3.2 AOF文件记录写操作方式
appendfsync always //实时记录,并完成磁盘同步
appendfsync everysec //每秒记录一次,并完成同步(默认)
appendfsync no //写入aof,不执行磁盘同步,满足存盘要求时再保存数据2.3.3 日志重写
auto-aof-rewrite-percentage 100 //再次重写,增长百分比
auto-aof-rewrite-min-size 64mb //首次重写触发值2.3.4 恢复AOF文件
]# redis-check-aof --fix appendonly.aof
把aof文件恢复到最后一次正确操作
2.4 AOF的优缺点
优点
- 数据的安全性高,提供了三种同步策略
1.1 每秒同步:也是一种异步同步.系统宕机时,会丢失最后一秒的数据
1.2 每修改同步:灭次发生的数据变化都会被记录到磁盘中.工作效率最低
1.3 无同步:那就是不同步数据 - 该机制对日志文件的写操作采用的时追加模式,因此及时发生宕机现象,也不会破坏日志文件中已经存在的内容.如果本次操作写了一半数据,系统宕机了,下次redis启动之前,我们可以通过redis-check-aof工具来解决数据一致性的问题.
- 如果日志文件过大,redis可以自动启用rewrite机制.在redis以追加的形式将修改数据写入到旧的磁盘文件中,同时redis还会创建一个新的文件用于记录此期间,有哪些修改命令被执行.因此rewrite切换时可以保证数据的安全性.
- AOF包含一个格式清晰,易于理解的日志文件用于记录所有的修改操作
缺点
- AOF文件通常大于RDB文件.RDB文件在恢复大数据集时的速度比AOF的恢复速度快.
- 根据同步策略的不同,AOF在运行效率上往往会慢于RDB.美妙同步策略的效率比较高,同步禁用的效率和RDB一样高效.
三、选择
如果希望高效的缓存一致性呢,势必会牺牲点性能那么选用AOF;
如果希望写操作频繁的高性能,那么建议RDB
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
