当前位置: 移动技术网 > IT编程>数据库>MongoDB > Redis的快照

Redis的快照

2018年03月29日  | 移动技术网IT编程  | 我要评论

selangwuyuetian,诸神学徒txt下载,盐山吧

博客链接:

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是命令,需要逐条执行

如对本文有疑问,请在下面进行留言讨论,广大热心网友会与你互动!! 点击进行留言回复

相关文章:

验证码:
移动技术网