博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
Redis持久化
阅读量:5820 次
发布时间:2019-06-18

本文共 2613 字,大约阅读时间需要 8 分钟。

hot3.png

概述

默认情况下,Redis为纯内存缓存,但可以配置Redis持久化,将数据保存到硬盘进行容灾。

Redis支持RDB和AOF两种方式持久化。

简单的说两种方式区别:

RDB:定时持久化数据,性能比AOF高,适合对数据安全性要求不太高的场景。

AOF:实时持久化数据,性能较RDB差,适合对数据安全性高的场景。

详细论述见:

RDB

修改redis.conf,启用RDB(默认已启用):

  • save <seconds> <changes>

    指出在多长时间内,有多少次更新操作,就将数据同步到数据文件rdb,可以同时配置多个。

    save 900 1    900秒内至少有1个key被改变

        save 300 10  300秒内至少有10个key被改变  

        save 60 10000  60秒内至少有10000个key被改变

  • dbfilename dump.rdb

    本地持久化数据库文件名,默认值为dump.rdb

  • dir ./

    数据库镜像备份的文件放置的路径。

    这里的路径跟文件名要分开配置。因为redis在进行备份时,先会将当前数据库的状态写入到一个临时文件中,等备份完成时,再把该该临时文件替换为上面所指定的文件,而这里的临时文件和上面所配置的备份文件都会放在这个指定的路径当中。

        AOF文件也会存放在这个目录下面。

        注意这里必须制定一个目录而不是文件。

AOF

修改redis.conf:

  • appendonly no

    only模式之后,redis会把所接收到的每一次写操作请求都追加到appendonly.aof文件中,当redis重新启动时,会从该文件恢复出之前的状态。

    但是这样会造成appendonly.aof文件过大,所以redis还支持了BGREWRITEAOF指令,对appendonly.aof 进行重新整理。

    你可以同时开启asynchronous dumps 和 AOF。

  • appendfsync everysec

    • Redis支持三种同步AOF文件的策略:

    • no: 不进行同步,系统去操作 . Faster.

    • always:表示每次有写操作都进行同步. Slow, Safest.

    • everysec: 表示对写操作进行累积,每秒同步一次.。默认是"everysec",按照速度和安全折中这是最好的。

    • 如果想让Redis能更高效的运行,你也可以设置为"no",让操作系统决定什么时候去执行。或者相反想让数据更安全你也可以设置为"always",如果不确定就用 "everysec"。

  • appendfilename appendonly.aof

    AOF文件名称 (默认: "appendonly.aof")

  • no-appendfsync-on-rewrite no

    AOF策略设置为always或者everysec时,后台处理进程(后台保存或者AOF日志重写)会执行大量的I/O操作。在某些Linux配置中会阻止过长的fsync()请求。注意现在没有任何修复,即使fsync在另外一个线程进行处理。为了减缓这个问题,可以设置下面这个参数no-appendfsync-on-rewrite。

备份 Redis 数据

在阅读这个小节前, 先将下面这句话铭记于心: 一定要备份你的数据库!

磁盘故障, 节点失效, 诸如此类的问题都可能让你的数据消失不见, 不进行备份是非常危险的。

Redis 对于数据备份是非常友好的, 因为你可以在服务器运行的时候对 RDB 文件进行复制: RDB 文件一旦被创建, 就不会进行任何修改。 当服务器要创建一个新的 RDB 文件时, 它先将文件的内容保存在一个临时文件里面, 当临时文件写入完毕时, 程序才使用 rename(2) 原子地用临时文件替换原来的 RDB 文件。

这也就是说, 无论何时, 复制 RDB 文件都是绝对安全的。

以下是我们的建议:

  • 创建一个定期任务(cron job), 每小时将一个 RDB 文件备份到一个文件夹, 并且每天将一个 RDB 文件备份到另一个文件夹。

  • 确保快照的备份都带有相应的日期和时间信息, 每次执行定期任务脚本时, 使用 find 命令来删除过期的快照: 比如说, 你可以保留最近 48 小时内的每小时快照, 还可以保留最近一两个月的每日快照。

  • 至少每天一次, 将 RDB 备份到你的数据中心之外, 或者至少是备份到你运行 Redis 服务器的物理机器之外。

容灾备份

Redis 的容灾备份基本上就是对数据进行备份, 并将这些备份传送到多个不同的外部数据中心。

容灾备份可以在 Redis 运行并产生快照的主数据中心发生严重的问题时, 仍然让数据处于安全状态。

因为很多 Redis 用户都是创业者, 他们没有大把大把的钱可以浪费, 所以下面介绍的都是一些实用又便宜的容灾备份方法:

  • Amazon S3 ,以及其他类似 S3 的服务,是一个构建灾难备份系统的好地方。 最简单的方法就是将你的每小时或者每日 RDB 备份加密并传送到 S3 。 对数据的加密可以通过 gpg -c 命令来完成(对称加密模式)。 记得把你的密码放到几个不同的、安全的地方去(比如你可以把密码复制给你组织里最重要的人物)。 同时使用多个储存服务来保存数据文件,可以提升数据的安全性。

  • 传送快照可以使用 SCP 来完成(SSH 的组件)。 以下是简单并且安全的传送方法: 买一个离你的数据中心非常远的 VPS , 装上 SSH , 创建一个无口令的 SSH 客户端 key , 并将这个 key 添加到 VPS 的 authorized_keys 文件中, 这样就可以向这个 VPS 传送快照备份文件了。 为了达到最好的数据安全性,至少要从两个不同的提供商那里各购买一个 VPS 来进行数据容灾备份。

需要注意的是, 这类容灾系统如果没有小心地进行处理的话, 是很容易失效的。

最低限度下, 你应该在文件传送完毕之后, 检查所传送备份文件的体积和原始快照文件的体积是否相同。 如果你使用的是 VPS , 那么还可以通过比对文件的 SHA1 校验和来确认文件是否传送完整。

另外, 你还需要一个独立的警报系统, 让它在负责传送备份文件的传送器(transfer)失灵时通知你。

转载于:https://my.oschina.net/tongyufu/blog/405638

你可能感兴趣的文章
环境变量(总结)
查看>>
ios之UILabel
查看>>
Java基础之String,StringBuilder,StringBuffer
查看>>
1月9日学习内容整理:爬虫基本原理
查看>>
安卓中数据库的搭建与使用
查看>>
AT3908 Two Integers
查看>>
渐变色文字
查看>>
C++ 0X 新特性实例(比较常用的) (转)
查看>>
node生成自定义命令(yargs/commander)
查看>>
各种非算法模板
查看>>
node-express项目的搭建并通过mongoose操作MongoDB实现增删改查分页排序(四)
查看>>
PIE.NET-SDK插件式二次开发文档
查看>>
如何创建Servlet
查看>>
.NET 设计规范--.NET约定、惯用法与模式-2.框架设计基础
查看>>
win7 64位+Oracle 11g 64位下使用 PL/SQL Developer 的解决办法
查看>>
BZOJ1997:[HNOI2010]PLANAR——题解
查看>>
BZOJ1014:[JSOI2008]火星人prefix——题解
查看>>
使用Unity3D引擎开发赛车游戏
查看>>
HTML5新手入门指南
查看>>
opennebula 开发记录
查看>>