Loading

（六）、Redis持久化

目录

RDB（Redis DataBase）

是什么

在指定的时间内将内存中的数据集快照写入磁盘，也就是Snapshot快照，它恢复时是将快照文件直接读到内存里

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

Fork

Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

配置位置

redis.conf配置文件下SNAPSHOTTING快照

image-20210811221048986

 save <seconds> <changes>
 save 120  5
 
# Note that you must specify a directory here, not a file name.   
dir  ./   #指定生成快照的文件位置  启动的当前目录

相当于120秒（2分钟）以内，只要key被改过5次就备份一次

配置文件方式验证效果

先删掉redis安装目录下的快照，然后插入5条数据，等待两分钟，指定目录下出现快照文件

[root@VM-4-15-centos myredis]# redis-server /root/myredis/redis.conf
[root@VM-4-15-centos myredis]# redis-cli -p 6379
127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k3 v3
OK
127.0.0.1:6379> set v4 v4
OK
127.0.0.1:6379> set k5 v5
OK
127.0.0.1:6379> set k6 v6
OK

这时候配置文件根目录下生成了一个dump.rdb文件，这就是快照文件

[root@VM-4-15-centos myredis]# ls
dump.rdb  redis.conf

关机之后再打开原来数据还在，是因为会从dump.rdb中加载数据

127.0.0.1:6379> shutdown
not connected> exit
[root@VM-4-15-centos myredis]# redis-server /root/myredis/redis.conf
[root@VM-4-15-centos myredis]# redis-cli -p 6379
127.0.0.1:6379> keys *
1) "k6"
2) "k5"
3) "k3"
4) "k2"
5) "k4"
6) "k1"

删除dump.rdb快照文件，之后再启动

[root@VM-4-15-centos myredis]# ls
dump.rdb  redis.conf
[root@VM-4-15-centos myredis]# rm dump.rdb
rm: remove regular file ‘dump.rdb’? y
[root@VM-4-15-centos myredis]# ls
redis.conf

之前退出后，再次启动redis，数据没有了

[root@VM-4-15-centos myredis]# redis-server /root/myredis/redis.conf
[root@VM-4-15-centos myredis]# redis-cli -p 6379
127.0.0.1:6379> keys *
(empty array)

触发RDB快照方法

  • 配置文件设置快照间隔时间，上面有示例

  • 命令save：save命令是阻塞命令，也就是当服务器接收了一条save命令之后就会开始拍摄快照，在此期间不会再去处理其他的请求，其他请求会被挂起直到备份结束

    执行save命令就会产生快照文件

  • 命令BGSAVE：Redis会在后台异步进行快照操作， 快照同时还可以响应客户端请求。可以通过lastsave 命令获取最后一次成功执行快照的时间

  • 命令shutdown：HUTDOWN时，会触发SAVE命令

  • 命令SYNC：redis发送SYNC命令后，主启动BGSAVE命令

    执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义

恢复

将备份文件 (dump.rdb) 移动到 redis 快照指定目录并启动服务即可

优势与劣势

优势

  • 适合大规模的数据恢复

  • 对数据完整性和一致性要求不高

劣势

  • 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就 会丢失最后一次快照后的所有修改
  • Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

总结

  • RDB是一个非常紧凑的文件。
  • RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他I0操作，所以RDB持久化方式可以最大化redis的性能。
  • 与AOF相比，在恢复大的数据集的时候，RDB方式会更快一一些。
    数据丢失风险大。
  • RDB需要经常fork子进程来保存数据集到硬盘上，当数据集比较大的时候fork的过程是非常耗时的吗，可能会导致Redis在一些毫秒级不能回应客户端请求。
  • 要进行大规模的数据恢复，但是精度要求不高，最好的方法就是RDB

AOF（Applend Only File）

是什么

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

配置位置

在APPEND ONLY MODE下

image-20210812215928832

修改no为yes，相当于打开aof的持久化

appendfilename "appendonly.aof"

默认名称appendonly.aof

其他配置信息

appendfsync包含以下三个参数

# appendfsync always
appendfsync everysec
# appendfsync no
  • 每修改同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
  • 每秒同步：appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失
  • 不同步：appendfsync no 从不同步

触发生成AOF的方法

首先将系统里面没有appendonly.aof文件，记录也为空

[root@VM-4-15-centos myredis]# ls
redis_AOF.conf  redis.conf
[root@VM-4-15-centos myredis]# redis-server /root/myredis/redis_AOF.conf
[root@VM-4-15-centos myredis]# redis-cli
127.0.0.1:6379> keys *
(empty array)

往数据库添加几条数据

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK

[root@VM-4-15-centos myredis]# ls
appendonly.aof  dump.rdb  redis_AOF.conf  redis.conf

路径下立马生成appendonly.aof日志文件，如果没有触发请先检查配置，再重启redis。

恢复

正常恢复：

  • 在设置了appendonly为yes的情况下会自动重新构建写入的数据，或者将文件复制到指定目录，重新启动redis就可以加载了

异常恢复：

  • 备份被写坏的文件
  • 利用Redis-check-aof --fix修复
  • 最后再次重启

AOF优化机制

no-appendfsync-on-rewrite no  #重写时是否运用appendfsync,默认用no
auto-aof-rewrite-percentage 100  #设置重写的基准值
auto-aof-rewrite-min-size 64mb  #文件大小阙值

因为AOF采用文件追加的形式，为避免文件越来越大，当文件查过设定的阙值，Redis就会启动AOF文件压缩，只保留可以恢复数据的最小指令集。可以使用命令bgrewriteaof

重写原理：

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

触发机制：

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

优势与劣势

优势

  • 每修改同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好

  • 每秒同步：appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失
    不同步：appendfsync no 从不同步

劣势

  • 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
  • Aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同

总结

img

  • AOF文件时一个只进行追加的日志文件
  • Redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写
  • AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以Redis协议的格式保存，因此AOF文件的内容非常容易被人读懂，对文件进行分析也很轻松
  • 对于相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积
  • 根据所使用的fsync 策略，AOF的速度可能会慢于RDB
posted @ 2021-08-24 15:49  炒焖煎糖板栗  阅读(34)  评论(0)  编辑  收藏  举报