首页 > 数据库 >【Redis高手修炼之路】③持久化

【Redis高手修炼之路】③持久化

时间:2022-10-30 10:32:06浏览次数:53  
标签:AOF dump 高手 Redis 备份 redis 修炼 文件 rdb


持久化

  • ​​1. RDB​​
  • ​​1.1 自动备份​​
  • ​​1.2 手动备份​​
  • ​​1.3 与RDB相关的配置​​
  • ​​2. AOF​​
  • ​​2.1 开启AOF​​
  • ​​2.2 共存?谁优先?​​
  • ​​2.3 与AOF相关的配置​​
  • ​​3 总结(如何选择?)​​

1. RDB

Redis DataBase

  • 在指定的时间间隔内,将内存中的数据集的快照写入磁盘;
  • 默认保存在/usr/local/bin中,文件名dump.rdb;

1.1 自动备份

redis是内存数据库,当我们每次用完redis,关闭linux时,按道理来说,内存释放,redis中的数据也会随之消失。为什么我们再次启动redis的时候,昨天的数据还在,并没有消失呢?

  • 是因为,每次关机时,redis会自动将数据备份到一个文件中:/usr/local/bin/dump.rdb

接下来我们就来全方位的认识 自动备份机制

  1. 默认的自动备份策略不利于我们测试,所以修改redis.conf文件中的自动备份策略
vim redis.conf
/SNAP # 搜索

【Redis高手修炼之路】③持久化_redis

save 900 1      #900秒内,至少变更1次,才会自动备份
save 300 10 #300秒内,至少变更10次,才会自动备份
save 60 10000 # 60秒内,至少变更10000次,才会自动备份

​注意:​​​ 如果你只是使用Redis的缓存功能,而不需要持久化,那么你就可以注释掉所有的save行停用该功能。然后可以直接一个空字符串来实现停用:​​save ""​

  1. 使用shutdown模拟关机,关机之前和关机之后,对比dump.rdb文件的时间
    ​​​注意:​​当我们使用shutdown命令,redis会自动将数据库备份。所以,dump.rdb文件创建时间会更新。
  2. 开机启动redis,然后在300秒内保存10条数据,再查看dump.rdb文件的更新时间(开两个终端窗口,方便查看)
  3. 300秒内保存10条数据这一动作触发了备份指令,所以目前的dump.rdb文件中保存了10条数据,将dump.rdb拷贝一份dump10.rdb,此时两个文件中都保存10条数据
  4. 既然有数据已经备份了,那我们就肆无忌惮的通过​​flushall​​命令将数据全部删除,再次shutdown关机
  5. 再次启动redis,发现数据真的消失了,并没有按照我们所想的将dump.rdb文件中的内容恢复到redis中。为什么?
因为,当我们保存10条以上的数据时,数据备份起来了;然后删除数据库,备份文件中的数据,也没问题;
但是,问题出在shutdown上,这个命令一旦执行,就会立刻备份,将删除之后的空数据库生成备份文件,
将之前装10条数据的备份文件覆盖掉了,所以自动恢复失败。怎么解决这个问题呢?要将备份文件再备份。
我们前面已经备份了一个dump10.rdb的文件。
  1. 将dump.rdb文件删除,然后将dump10.rdb重命名为dump.rdb
  2. 启动redis服务,登录redis,发现10条数据全部恢复!

1.2 手动备份

之前自动备份,必须更改好多数据,例如上边,我们改变了十多条数据,才会自动备份;现在,我只保存一条数据,就想立刻备份,应该怎么做?每次操作完成,执行命令 save 就会立刻备份

1.3 与RDB相关的配置

​stop-writes-on-bgsave-error​​:进水口和出水口,出水口发生故障与否

  • yes:当后台备份时候反生错误,前台停止写入
  • no:不管死活,就是往里怼

​rdbcompression​​:对于存储到磁盘中的快照,是否启动LZF压缩算法,一般都会启动,因为这点性能,多买一台电脑,完全搞定N个来回了。

  • yes:启动
  • no:不启动(不想消耗CPU资源,可关闭)

​rdbchecksum​​:在存储快照后,是否启动CRC64算法进行数据校验;

  • 开启后,大约增加10%左右的CPU消耗;
  • 如果希望获得最大的性能提升,可以选择关闭;

​dbfilename​​​:快照备份文件名字
​​​dir​​:快照备份文件保存的目录,默认为当前目录

优势and劣势

  • 优势:适合大规模数据恢复,对数据完整性和一致行要求不高;
  • 劣势:一定间隔备份一次,意外down掉,就失去最后一次快照的所有修改

2. AOF

Append Only File

  • 以日志的形式记录每个写操作;
  • 将redis执行过的写指令全部记录下来(读操作不记录);只许追加文件,不可以改写文件;
  • redis在启动之初会读取该文件从头到尾执行一遍,这样来重新构建数据;

2.1 开启AOF

  1. 为了避免失误,最好将redis.conf总配置文件备份一下,然后再修改内容如下:
appendonly yes
appendfilename "appendonly.aof"

【Redis高手修炼之路】③持久化_数据库_02


​注意:​​编辑这个文件,最后要 :wq! 强制执行

  1. 重新启动redis,以新配置文件启动
redis-server /opt/redis-5.0.4/redis.conf
  1. 连接redis,加数据,删库,退出
  2. 查看当前文件夹发现多一个aof文件,看看文件中的内容,保存的都是 写 操作
  3. 文件中最后一句要删除,否则数据恢复不了
  4. 【Redis高手修炼之路】③持久化_数据库_03

  5. 只需要重新连接,数据恢复成功!

2.2 共存?谁优先?

我们查看redis.conf文件,AOF和RDB两种备份策略可以同时开启,那系统会怎样选择?

  1. 编辑appendonly.aof,在文件中随便乱写一串代码,保存退出
  2. 启动redis ,结果失败,所以是AOF优先载入来恢复原始数据!因为AOF比RDB数据保存的完整性更高!
  3. 修复AOF文件,通过下面命令杀光不符合redis语法规范的代码
reids-check-aof --fix appendonly.aof

2.3 与AOF相关的配置

​appendonly​​​:开启aof模式 appendfilename:aof的文件名字,最好别改!
​​​appendfsync​​:追写策略

  • always:每次数据变更,就会立即记录到磁盘,性能较差,但数据完整性好
  • everysec:默认设置,异步操作,每秒记录,如果一秒内宕机,会有数据丢失
  • no:不追写

​no-appendfsync-on-rewrite​​:重写时是否运用Appendfsync追写策略;用默认no即可,保证数据安全性。

  • AOF采用文件追加的方式,文件会越来越大,为了解决这个问题,增加了重写机制,redis会自动记录上一次AOF文件的大小,当AOF文件大小达到预先设定的大小时,redis就会启动 AOF文件进行内容压缩,只保留可以恢复数据的最小指令集合

​auto-aof-rewrite-percentage​​​:如果AOF文件大小已经超过原来的100%,也就是一倍,才重写压缩
​​​auto-aof-rewrite-min-size​​:如果AOF文件已经超过了64mb,才重写压缩

3 总结(如何选择?)

  • RDB:只用作后备用途,建议15分钟备份一次就好
  • AOF:
  • 在最恶劣的情况下,也只丢失不超过2秒的数据,数据完整性比较高,但代价太大,会带来持续的IO
  • 对硬盘的大小要求也高,默认64mb太小了,企业级最少都是5G以上;
  • 后面要学习的master/slave才是新浪微博的选择!!


标签:AOF,dump,高手,Redis,备份,redis,修炼,文件,rdb
From: https://blog.51cto.com/u_15309887/5807356

相关文章

  • 《程序员修炼之道:从小工到专家》读后感4
    本次我学习了第一章第三节和第四节。第三节讲的是石头汤与煮青蛙。石头汤主要讲了一帮士兵通过技巧将一帮村民团结起来,得到了一锅丰盛的汤。这个故事可以从两个视......
  • 记录一次redis分布式锁的坑
    redis分布式锁的实现方式是:lock(){sync(this){//无法获取自旋setnx(key,UUID)setex(60s)returnUUID}}unlock......
  • Redis无法在Arm平台启动的问题
    这是继前文在Arm平台部署遇到的另一个问题,拉取Arm平台下的各服务镜像后,启动时却发现redis无法启动,进行了诊断后发现错误提示如下:redis|1:M28Oct202204:02:33.981#......
  • 《程序员修炼之道读后感》
    注重实效的途径 想法和过程集中在一起,头两节的偏向于“重复的危害”和“正交性”密切相关,前者告诉我们,不要在系统各处对知识进行重复,后者告诉我们不要把同样的知识分散......
  • 程序员修炼之道:从小工到专家 阅读笔记4
    Bug是一个程序员必须要面对的东西,在处理bug的时候,有些事情就显得尤为重要。发现bug后你应该专注于修正问题而不是指责,bug是你的过错还是别人的过错,并没有关系,你应该考虑的......
  • 程序员修炼之道:从小工到专家 阅读笔记3
    我是先读的本书的利用好shell编程,内容大致如下,可以通过对shell编程,构建复杂的宏命令,,完成你经常进行的各种活动。利用命令shell的力量,熟悉shell,你自己的生产率迅速提高,多花......
  • 程序员修炼之道笔记4
    第六节:交流1、知道你想要说什么当我们面临会议,重要通话,或者只是撰写技术文档,问下自己你要表达的中心想法是什么,围绕这一点进行展开。2、了解你的听众比如你要做一场分......
  • 程序员修炼之道笔记3
    第五节:你的知识资产1、本杰明·富兰克林说过:知识上的投资总能得到最好的回报。这没问题,但遗憾的是知识是有时效的资产,特别是计算机领域。我们可以把我们了解的技术实现、......
  • 《程序员修炼之道:从小工到专家》读后感3
    本次我阅读的是第一章第二节,软件的熵。熵本是物理学中的概念,是对一个系统的混乱程度的描述,即“无序”的总量。对于宇宙这个系统,由热力学定律可知熵增是不可逆转的。当......
  • 《程序员修炼之道——从小工到专家》第四章
      “YouCan'tWritePerfectSoftware.”。这是第四章的开篇语,直接了当的告诉了我们,在程序设计中写出一份十全十美的程序是不可能的。一名有时效的程序员连自己都“不......