欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

Redis的快照

程序员文章站 2024-01-09 19:00:04
博客链接:http://www.cnblogs.com/zhenghongxin/p/8669913.html redis 本地持久化到硬盘有两种方式,一是快照(snapshotting),二是只追加文件(append-only file AOF) 快照 快照,顾名思义可以理解为拍照一样,把整个内存 ......

博客链接:http://www.cnblogs.com/zhenghongxin/p/8669913.html

redis 本地持久化到硬盘有两种方式,一是快照(snapshotting),二是只追加文件(append-only file AOF)

快照

快照,顾名思义可以理解为拍照一样,把整个内存数据映射到硬盘中,保存一份到硬盘,因此恢复数据起来比较快,把数据映射回去即可,不像AOF,一条条的执行操作命令。产生快照的过程:

1 执行bgsave命令(此时redis会fork一个子进程,子进程负责生成硬盘文件,父进程负责继续接受命令)

2 或执行save命令(和bgsave命令不同,发送save命令后,到系统创建快照完成之前系统不会再接收新的命令,换句话说save命令会阻塞后面的命令,而bgsave不会)

3 用户在配置文件了配置了类似这样的命令
    save 900 1 // 900内,有1条写入,则产生快照

   save 300 1000 // 如果300秒内有1000次写入,则产生快照

   save 60 10000 // 如果60秒内有10000次写入,则产生快照

   (这3个选项都屏蔽,则rdb禁用)

4 用户发送shutdown,系统会先导员save命令阻塞客户端,然后关闭服务器
5 当有主从架构时,从服务器向主服务器发送sync命令来执行复制操作时,只有主服务器当时没有进行bgsave操作,那么主服务器就会执行bgsave操作。

我们可以在redis目录下查看redis.conf配置,其中某些重要配置:

stop-writes-on-bgsave-error yes // 后台备份进程出错时,主进程停不停止写入?

rdbcompression yes // 导出的rdb文件是否压缩

Rdbchecksum yes // 导入rbd恢复时数据时,要不要检验rdb的完整性

dbfilename dump.rdb //导出来的rdb文件名

dir ./ //rdb的放置路径

快照的优势

1) 通过合理的配置,可以让Redis每隔一段时间就保存一次数据库副本,也可以很方便地将数据还原到特定的时间点。

2)RDB文件相比AOF占用的空间更小,恢复数据的速度也更快。

3)如果创建RDB文件时出现了错误,Redis不会将它用于替换原来的文件,所以出错时不会影响到之前保存的版本。

快照的缺点

1) 如果硬件、系统、Redis三者其中之一出现问题而崩溃,Redis会丢失全部数据,保留下来的数据只有上一个时间点创建的快照。如果数据对于应用程序来说非常重要,那么出现错误时的损失会非常大。

2)fork子进程占用的内存随着数据库中数据的增加而增加,耗费的时间也会越来越多

一些问答:

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

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

: aof重写是指什么?

答: aof重写是指把内存中的数据,逆化成命令,写入到.aof日志里.以解决 aof日志过大的问题.

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

答: aof

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

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

一般来说,如果想达到足以媲美 PostgreSQL 的数据安全性, 你应该同时使用两种持久化功能。如果你非常关心你的数据,但仍然可以承受数分钟以内的数据丢失, 那么你可以只使用 RDB 持久化。有很多用户都只使用 AOF 持久化, 但我们并不推荐这种方式: 因为定时生成 RDB 快照(snapshot)非常便于进行数据库备份, 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快, 除此之外, 使用 RDB 还可以避免之前提到的 AOF 程序的 bug 。因为以上提到的种种原因, 未来我们可能会将 AOF 和 RDB 整合成单个持久化模型。 (这是一个长期计划。)

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

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