redis数据持久化详解

本文详细介绍了Redis的两种持久化方式——RDB和AOF,包括各自的优缺点。RDB提供紧凑的数据快照,适合数据备份,而AOF则记录每次写操作,保证高耐久性。同时,文章讨论了如何选择合适的持久化方式以及如何配置相关参数。此外,还阐述了Redis的数据备份策略,包括定期备份和容灾备份的方法,强调了数据安全的重要性。
摘要由CSDN通过智能技术生成

一、概念
一)redis提供了不同级别的持久化方式:

  1. RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储。
  2. AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾,redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大。
  3. 如果你只希望你的数据在服务器运行的时候存在,你也可以不适用任何持久化方式。
  4. 也可以同时开启两种持久化方式,在这种情况下,当redis重启的时候会有限载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集比RDB文件保存的数据集要完整

二)RDB的优缺点
优点:

  1. RDB是一个非常紧凑的文件,它保存了某个时间点的数据集,非常适用于数据集的备份,这样即使出了问题你也可以根据需求恢复到不同版本的数据集。
  2. RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心或者亚马逊的S3(可能加密),非常适用于灾难恢复。
  3. RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做,父进程不需要再做其他IO操作,所以RDB持久化方式可以最大化redis的性能。
  4. 与AOF相比,在恢复大的数据集的时候,RDB方式会更快一些。

缺点:

  1. 如果希望在redis意外停止工作的情况下丢失的数据最少的话,那么RDB不适合
  2. RDB需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致redis在一些毫秒级内不能相应客户端的请求。

三)AOF的优缺点
优点:

  1. 使用AOF会让你的redis更加耐久
  2. AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满,写的过程中宕机等)未执行完整的写入命令,你也可使用redis-check-aof工具修复这些问题。
  3. redis可以在aof文件体积变得过大时,自动的在后台对aof进行重写。
  4. aof文件有序地保存了对数据库执行的所有写入操作,这些写入操作以redis协议的格式保存,因此aof文件的内容非常容易被人读懂,对文件进行分析(parse)也很轻松。

缺点:

  1. 对于相同的数据集来说,aof文件的体积通常要大于rdb文件的体积。
  2. 根据所使用的fsync策略,aof的速度可能会慢于rdb

四)如何选择使用哪种持久化方式:

  1. 一般来说,如果想达到足以媲美PostgreSQL的数据安全性,你应该同时使用两种持久化功能。
  2. 如果非常关心你的数据,但仍然可以承受数分钟以内的数据丢失,那么你可以只使用RDB持久化。
  3. 不推荐只是用AOF持久化,因为定时生成RDB快照(snapshot)非常便于进行数据库备份,并且RDB恢复数据集的速度也要比AOF恢复的速度要快。

五)更多RDB细节:

  1. 在默认情况下,redis将数据库快照保存在名字为dump.rdb的二进制文件中。
  2. 这种持久化方式被称为快照snapshotting
  3. 当redis需要保存dump.rdb文件时,服务器执行以下操作:
    • redis调用forks,同时拥有父进程和子进程。
    • 子进程将数据集写入到一个临时RDB文件中。
    • 当子进程完成对新RDB文件的写入是,redis用新RDB文件替换原来的RDB文件,并删除旧的RDB文件


二、redis数据持久化相关配置以及命令
一)RDB的配置:
1、在配置文件中已经预设三个条件

  • save 900 1 #15分钟内至少有一个键被更改
  • save 300 10 #5分钟内至少有10个键被更改
  • save 60 10000 #1分钟内至少有10000个键被更改

2、默认的rdb文件路径是当前目录,文件名是:dump.rdb,可以在配置文件中修改路径和文件名,分别是dir和dbfilename

  • dir ./ #rdb文件存储路径
  • dbfilename dump.rdb #rdb文件名

3、RDB文件的压缩:

  • RDB文件是通过压缩的,可以通过配置rdbcompression参数来禁用压缩,redis默认是开启压缩的。

4、RDB相关命令:

  • 如果没有触发自动快照,需要对redis执行手动快照操作,save和bgsave都是执行手动快照,但是两者有区别:可以通过save和bgsave命令来手动快照,两个命令的区别是前者是由主进程进行快照,会阻塞其他请求,后者是通过fork子进程进行快照。

二)AOF(Append-Only File)
1、快照功能并不是非常耐久(dura ble):如果redis因为某些原因而造成故障停机,那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。从1.1版本开始,redis增加了一种完全耐久的持久化方式:AOF持久化。
2、可以在配置文件中打开AOF方式:

  • appendonly yes

3、从现在开始,每当redis执行一个改变数据集的命令时(比如set),这个命令就会被追加到AOF文件的末尾。

4、AOF工作原理:
1)redis执行fork(),现在同时拥有父进程和子进程
2)子进程开始将新AOF文件的内容写入到临时文件
3)对于所有新执行的写入命令,父进程一边将他们累积到一个内存缓存中,一边将这些改动追加到现有AOF文件的末尾,这样即使在重写的中途发生停机,现有的AOF文件也还是安全的
4)当子进程完成重写工作时,它给父进程发送一个信号,父进程在接收到信号之后,将内存缓存中的所有数据追加到新AOF文件的末尾

5、日志重写
1)AOF文件的体积会变得越来越大
2)重建(rebuild)
3)bgrewriteaof命令
4)自动触发AOF重写

6、AOF相关配置
1)AOF文件的位置和RDB的位置相同,都是通过dir参数设置,默认的文件名是appendonly.aof,可以通过appendfilename参数修改
2)重写策略的参数设置

  • auto-aof-rewrite-percentage 100
  • 当前的AOF文件大小超过上一次重写的AOF文件大小的百分之多少时会再次进行重写,如果之前没有重写过,则以启动时的AOF大小为依据
  • auto-aof-rewrite-min-size 64mb
  • 限制了允许重写的最小AOF文件

3)文件同步策略

  • 文件写入默认情况下会先写入到系统的缓存中,系统每个30秒同步一次,才是真正的写入到磁盘,如果在这30秒服务器宕机那数据也会丢失
  • appendfsync always每次都同步(最安全但是最慢)
  • appendfsync everysec每秒同步(默认的同步策略)
  • appendfsync no 不主动同步,由操作系统来决定(最快但是不安全)

7、优化AOF文件:

  • 可以使用BGREWRITEAOF命令来重写AOF文件。目的是去除数据的中间执行过程,保存最终数据命令即可。

8、AOF文件损坏
1)为现有的AOF文件创建一个备份
2)使用redis-check-aof修复

  • redis-check-aof --fix
  • (可选)使用diff -u对比修复后的AOF文件和原始AOF文件的额备份,查看两个文件之间的不同之处。
  • 重启redis服务器,等待服务器载入修复后的AOF文件,并进行数据恢复。

9、怎样从RDB方式切换为AOF方式:
1)为最新的dump.rdb文件创建一个备份
2)将备份放到一个安全的地方
3)执行以下两条命令

  • redis-cli config set appendonly yes
  • redis-cli config set save ""

4)确保写命令会被正确的追加到AOF文件的末尾

三、redis数据备份
一)数据备份
1、确保你的数据由完整的备份(磁盘故障,节点失效,诸如此类的问题都可能使数据丢失,不进行备份是非常危险的)
2、无论何时,赋值RDB文件都是绝对安全的。

二)备份步骤
1)创建一个定期任务,每小时将一个RDB文件备份到一个文件夹,并且每天将一个RDB文件备份到另一个文件夹。
2)确保快照的备份都带有相应的日期和时间信息,每次执行定期任务脚本是,使用find命令来删除过期的快照:比如说,可以保留最近48小时内的每小时快照,还可以保留最近一两个月的每日快照。
3)至少每天一次,将RDB备份到你的数据中心之外,或者至少是备份到你运行redis服务器的屋里机器之外

三)容灾备份:
1)对数据进行备份,并将这些备份传送到多个不同的外部数据中心。
2)容灾备份可以在redis运行并产生快照的主数据中心发生严重的问题是,仍然让数据处于安全状态。

四)容灾备份方法:
1)Amazon S3
2)传送快照可以使用SCP来完成(ssh的组件)
3)在文件传送完毕之后,检查所传送备份文件的体积和原始文件的体积是否相同。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值