Redis_持久化之RDB

redis持久化包括rdb和aof两种方案

Save the DB on disk

save 900 1

 

优势:同步策略always->每次修改同步,性能差但完整性好;同步策略everysec->每秒同步,异步操作,如果一秒内down机会丢失数据;no->从不同步

# This base size is compared to the current size. If the current size
is
# bigger than the specified percentage, the rewrite is triggered.
Also
# you need to specify a minimal size for the AOF file to be rewritten,
this
# is useful to avoid rewriting the AOF file even if the percentage
increase
# is reached but it is still pretty small.
#
# Specify a percentage of zero in order to disable the automatic AOF
# rewrite feature.

save 60 10000

图片 1

2、aof持久化方案

 

  • 恢复数据:将appendonly.aof文件复制到config get
    dir对应的目录,并重启redis
  • 重写机制:appendonly.aof的内容是以追加的方式添加的,如果没有特殊机制,该文件会越来越大,为避免这个情况,redis针对aof持久化方式有重写机制  

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

重写过程:当aof文件超过配置的阈值(满足配置文件的配置的策略),redis会fork出一个进程,该进程遍历内存中的数据,每条记录都对应一条set语句,写入临时的aof文件,重写完成后,用临时文件替换上次的持久化文件。

是什么:

优势:适合对数据完整性和一致性要求不高的场景;适合大规模的数据恢复

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

  •  持久化过程:按照redis.conf文件配置,如

快照:

 图片 2

3、疑问

劣势:

,根据同步策略为everysec,则每秒将写操作追加(读操作不会追加)到appendonly.aof文件。

 

劣势:a、aof文件远大于rdb文件

应该使用哪种?

  • 持久化过程:按照redis.conf文件配置,如

appendonly yes  默认为no,改为yes为打开持久化开关

  • 触发落盘:满足配置的策略、使用flushdb、使用flushall(效果是所用数据都删除了,落盘后dump.rdb(默认文件名,可配置)文件内容为空)
  • 恢复数据:将dump.rdb复制到安装redis目录,并启动redis的服务。(连上redis后可以使用config
    get dir 获取redis的安装目录)

优势:

#appendfsync always

 

劣势:a、在一定间隔时间落盘一次,如果redis意外down,会吊事最后一次的redis中所有修改

# The default is “everysec”, as that’s usually the right compromise
between
# speed and data safety. It’s up to you to understand if you can relax
this to
# “no” that will let the operating system flush the output buffer
when
# it wants, for better performances (but if you can live with the idea
of
# some data loss consider the default persistence mode that’s
snapshotting),
# or on the contrary, use “always” that’s very slow but a bit safer
than
# everysec.
#
# More details please check the following article:
# http://antirez.com/post/redis-persistence-demystified.html
#
# If unsure, use “everysec”.

       b、数据恢复速度慢于rdb

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

,在指定时间间隔内满足数据落盘策略时候,redis会fork一个和原进程一模一样的子进程,该进程先将数据存到一个临时文件里,待持久化结束后,用临时文件替换上次的持久化文件。

3.AOF 会有什么优缺点

是不是只使用aof持久化方式呢?

如何恢复:

#appendfsync no

    Aof运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同

   b、fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑

 

如果两种持久化方式都配置了,那么redis重启时候,从哪里恢复数据呢?
从appendonly.aof文件恢复,因为aof持久化的数据更精确

# However if you have setup your proper monitoring of the Redis
server
# and persistence, you may want to disable this feature so that Redis
will
# continue to work as usual even if there are problems with disk,
# permissions, and so forth.
stop-writes-on-bgsave-error yes

appendfsync everysec

官网介绍:

save 300 10

2.AOF 为什么会在RDB 之后产生?

 

AOF启动/修复/恢复

1、rdb持久化方案

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

AOF

  1分钟内改了1万次,

rdbchecksum:在存储快照后,还可以让redis使用CRC64算法来进行数据校验,但这样会增加大约10%的性能消耗,如果希望获取到最大的性能提升,可以关闭此功能,不过一般不用关,可以再空闲时进行压缩和校验

Rewrite:

图片 3

  Fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑

  或15分钟内改了1次。

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

  Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量,环境变量,程序计数器等)数值都是和原进程一致,但是是一个全新的进程,并作为原进程的子进程。(存在一个问题:如果原程序的数据数据特别大,fork一份)

# after 900 sec (15 min) if at least 1 key changed
# after 300 sec (5 min) if at least 10 keys changed
# after 60 sec if at least 10000 keys changed
#
# Note: you can disable saving completely by commenting out all “save”
lines.
#

  在一定间隔时间做一次备份,所以如果redis意外down掉的话,就会丢失最后一次快照后的所有修改

  优势:

    恢复:重启redis然后重新加载

rdb – Redis DataBase

如何停止:

  CONFIG GET dir获取目录

# Since version 5 of RDB a CRC64 checksum is placed at the end of the
file.
# This makes the format more resistant to corruption but there is a
performance
# hit to pay (around 10%) when saving and loading RDB files, so you can
disable it
# for maximum performances.
#
# RDB files created with checksum disabled have a checksum of zero that
will
# tell the loading code to skip the check.
rdbchecksum yes

Fork:

    Save:save是只管保存,其他不管,全部阻塞

    每秒同步:appendfsync always 同步持久化
每次发生数据变更会被立即记录到磁盘,性能较差但数据完整性比较高

 

    启动:设置Yes

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# The DB will be written inside this directory, with the filename
specified
# above using the ‘dbfilename’ configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir ./

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

  异常恢复:

aof在文件被破坏后可以使用如下命令修复

Rdb 保存的是dump.rdb文件

相关文章