redis(三)redis持久化

目录

• 持久化方式


• RDB
  
  
  
  • RDB工作机制
  
  
  • 保存策略
  
  
  • RDB属性设置
  
  
  • 触发持久化的方式
  
  
  • 优缺点
  
  
  
  


• AOF
  
  
  
  • 保存策略
  
  
  • AOF属性设置
  
  
  • AOF文件的修复
  
  
  • AOF的rewrite机制
  
  
  • 优缺点
  
  
  
  


• 应用场景

持久化方式

redis主要工作在内存中。内存本省就不是一个持久化的设备，断电后数据会清空。但是redis提供了持久化方式。个人看来 这是redis提供了一种备份机制，可以将内存中的数据持久化到磁盘上，有利于这些热点数据的备份恢复和迁移。

redis提供了两种持久化方式，分别是RDB 和AOF

RDB持久化方式能够在指定的时间间隔对数据进行快照存储

AOF持久化方式记录每次对服务器的写操作，当服务器重启的时候会重新执行这些命令来恢复原始数据，个人认为类似于MySQL的binlog日志

RDB

RDB：在指定的时间间隔内将内存中的数据写入磁盘，它恢复时是将文件读取到内存中。

RDB是默认开启的

RDB工作机制

工作机制：每隔一段时间，就会把内存中的数据保存到硬盘上的指定文件中。

RDB在持久化时会单独创建一个fork子进程来进行持久化操作，会先将数据写入到一个临时文件中，等到持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。

整个过程中，主进程work是不会进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模的数据恢复，RDB性能比AOF好很多。

保存策略

save 900 1 900 秒（15分钟）内如果至少有 1 个 key 的值变化，则保存

save 300 10 300 秒（5分钟）内如果至少有 10 个 key 的值变化，则保存

save 60 10000 60 秒（1分钟）内如果至少有 10000 个 key 的值变化，则保存

save "" 是禁用RDB模式

RDB属性设置

触发持久化的方式

1、基于自动保存策略

2、执行save，或者bgsave命令，执行时save时是阻塞状态

3、执行 shutdown 命令时，也会主动地备份数据。

4、执行 flushdb 命令，也会产生 dump.rdb，但里面是空的，没有意义

优缺点

优点

1、RDB是一个文件，保存了某个时间点的数据集，非常适合用于数据集的备份。

2、压缩格式 恢复速度快

缺点

1、（可能有 但是我没找到）没有设置固定大小的策略，随着业务量的增加 只能任由rdb文件增大

2、不是实时的，可能会丢数据，操作比较重。

3、fork时内存中的数据被克隆了一份，大概2倍的膨胀。



备份脚本

每小时备份一次rdb文件
crontab -e
0 */1 * * * cp /etc/redis/dump.rdb /etc/redis/dump.rdb`date +%Y%m%d%H`


AOF

1、AOF是以日志的形式来记录每个写操作，将每一次对数据进行修改，都会把新建、修改数据的命令保存到指定文件中。redis重新启动时读取这个文件，重新执行新建、修改数据的命令恢复数据。

2、默认不开启，需要手动启动

3、AOF 在保存命令的时候，只会保存对数据有修改的命令，也就是写操作！

4、当 RDB 和 AOF 存的不一致的情况下，按照 AOF 来恢复。因为 AOF 是对 RDB 的补充。备份周期更短，也就更可靠。

保存策略

appendfsync always：每次产生一条新的修改数据的命令都执行保存操作；效率低，但是安全！

appendfsync everysec：每秒执行一次保存操作。如果在未保存当前秒内操作时发生了断电，仍然会导致一部分数据丢失（即 1 秒钟的数据）。

appendfsync no：从不保存，将数据交给操作系统来处理。更快，也更不安全的选择。推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。

AOF属性设置

AOF文件的修复

如果 AOF 文件中出现了残余命令，会导致服务器无法重启。此时需要借助 redis-check-aof 工具来修复！

命令： redis-check-aof –fix 文件

AOF的rewrite机制

AOF采用文件追加方式，文件会越来越大，为了避免出现这种情况，新增加了重写机制，当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。可以使用命令bgrewriteaof

重写原理

AOF文件持续增长而过大时，会fork出一条新进程来将文件重新（也就是先写临时文件最后rename），遍历新进程的内存中数据，每条记录有一条set语句。重写AOF文件的操作，并没有读取旧的AOF文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件，这点和RDB快照相似。

触发机制

redis会记录上次重写时AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大小大于64M时触发。

优缺点

优

1、备份机制更稳健，丢数据概率更低

2、可读的日志文本，通过操作AOF文件，可以处理误操作。

缺

1、比起RDB占用更多的磁盘空间

2、恢复备份速度要慢

3、每次读写都同步的话，有一定的性能压力

两种备份方式的有优先级

如果同时开启两种持久化方式：

在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

RDB的数据不是实时的，同时使用两者时服务器重启也只会找AOF文件。那要不要只用AOF呢？

也不建议，因为RDB更适合备份数据库，进行快速重启。

应用场景

一、服务器卡死或者redis卡死

如果数据不是很重要 建议直接使用RDB恢复。

恢复步骤：

1、移动AOF文件（因为默认是从AOF文件reload）

2、检查RDB文件 进行redis restart 重新reload RDB文件

二、人为误删除部分数据

数据不重要：删除了就删除吧

数据重要：AOF恢复

三、人为误删除全部数据

数据不重要：使用crontab 定时备份任务 备份的RDB文件进行恢复

数据重要：使用AOF的方式，vim appendonly.aof文件，将flushall命令删除后进行重启redis

四、误删除AOF文件

误删除了 就是没了。只能从现在再开始记录。

五、误删除RDB文件

save \bgsave触发条件会再次自动生成dump.rdb 是无所谓的

因为你不会，所以你才会---大司马