目录
2.1.3 stop-writes-on-bgsave-error
2.3.3 客户端shutdown会立刻刷新dump.rdb文件
3.1.5 no-appendfsync-on-rewrite
3.1.6 auto-aof-rewrite-percentage
3.1.7 auto-aof-rewrite-min-size
1.RDB和AOF是什么
其实很多答案技术官网都有写而且写的非常详细,官网地址:https://redis.io/topics/persistence
RDB (Redis Database):按指定的时间间隔执行数据集的时间点快照
AOF (Append Only File):记录服务器接收的每个写入操作,采用仅追加方式将命令写入AOF文件,服务启动时再重新执行AOF文件中的命令以达到恢复数据的目的。使用与Redis协议本身相同的格式记录命令,具有很好的可读性。当日志太大时,Redis可以在后台重写日志(rewrite机制)。
2.RBD2.1 配置参数
2.1.1 配置文件位置
redis.conf中SNAPSHOTTING部分
2.1.2 save
如果给定的秒数和对数据库执行的写入操作数都达到设定的阈值,则执行数据库持久化,通俗易懂的讲:配置RBD备份频率,默认行为:
- 900秒(15分钟)后,如果至少有一个键更改
- 300秒(5分钟)后,如果至少有10个键更改
- 60秒后,如果至少10000个键发生更改
2.1.3 stop-writes-on-bgsave-error
默认情况下,如果启用RDB快照,Redis将停止接受写操作。这将使用户意识到(通过报错的方式)数据没有持久化。如果后台保存过程将重新开始工作,Redis将自动允许再次写入。但是,如果您已经设置了对Redis服务器的适当监视和持久性,您可能希望禁用此功能。通俗易懂的讲:此参数设为no,表示在进行RDB持久化时主进程将停止接受读写操作;设置成yes,表示在进行RDB持久化时主进程将继续接受读写操作,数据不一致的问题交由用户自己处理。
2.1.4 rdbcompression
对于存储到磁盘中的快照文件,设置是否进行压缩,redis采用LZF压缩算法,如果想节省CPU性能可以关闭此功能,默认yes。
2.1.5 rdbchecksum
存储快照后,还可以让redis使用CRC64算法进行数据校验,但是这样做大约会增加10%性能损耗,如果想获得最大性能可关闭此功能,默认yes。
2.1.6 dbfilename
将数据库转储到的文件名,默认dump.rdb
2.1.7 dir
工作目录,数据库中的数据将被写入这个目录,请注意必须在此处指定目录,而不是文件名,默认当前路径。
2.2 fork
fork的作用是复制一个与当前进程一样的进程,新进程的所有数据(变量、环境变量、程序计数器等)都和原进程一致,并作为原进程的子进程。
2.3 如何触发RDB快照
2.3.1 配置文件中默认的快照配置
save 900 1
save 300 10
save 60 10000
2.3.2 客户端使用命令save或者bgsave
save:执行save命令时只管保存,其他命令阻塞
bgsave:bgsave命令会在后台异步进行快照操作,快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间
2.3.3 客户端shutdown会立刻刷新dump.rdb文件
客户端使用shutdown会立刻刷新dump.rdb文件,前提是开启了RBD持久化
2.4 如何恢复
如果需要恢复数据,只需将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可。获取 redis 目录可以使用 CONFIG 命令:
CONFIG GET dir
2.5 RBD的优势
(1)RDB是Redis数据的非常紧凑的单文件时间点表示。例如,您可能希望在最近24小时内每小时归档一次RDB文件,并在30天内每天保存一个RDB快照。这允许您在发生灾难时轻松恢复数据集的不同版本。
(2)RDB对于灾难恢复非常好,它是一个单一的压缩文件,可以传输到远端的数据中心,或者传输到AmazonS3(可能是加密的)。
(3)RDB最大限度地提高了Redis的性能,因为Redis父进程要持久化,唯一需要做的工作就是派生一个子进程来完成其余的工作。父实例永远不会执行磁盘I/O或类似操作。
(4)与AOF相比,RDB允许使用大数据集更快地重新启动。
2.6 RBD的劣势
(1)数据风险大,RDB采用在一定时间间隔内做一次备份,如果redis服务意外down掉,就会丢失最后一次未备份的修改
(2)fork子进程进行备份时,内存中的数据被克隆了一份,需要考虑数据2倍膨胀的问题
3.AOF3.1 配置参数
3.1.1 配置文件位置
3.1.2 appendonly
仅附加文件是一种提供更好的耐用性。例如,使用默认数据fsync策略(请参阅后面的配置文件)Redis在一段时间内只会丢失一秒钟的写操作。AOF和RDB持久性可以同时启用而不会出现问题。如果启动时启用了AOF,Redis将加载AOF,即文件具有更好的耐久性保证。通俗易懂的讲:启用AOF持久化
3.1.3 appendfilename
仅附加文件的名称,默认:appendonly.aof
3.1.4 appendfsync
fsync()调用告诉操作系统在磁盘上实际写入数据,而不是在输出缓冲区中等待更多的数据。appendfsync有三个参数,默认:everysec
no:不要fsync,只要让操作系统在需要时刷新数据即可,更快。
always:每次执行写入操作后进行fsync。慢,最安全。
everysec:每秒同步一次。
3.1.5 no-appendfsync-on-rewrite
重写时(下面会讲到rewrite)是否可以使用appendfsync,默认:no,可以保证数据安全性。
3.1.6 auto-aof-rewrite-percentage
设置重写规则(下面会讲到rewrite)的文件大小倍率基准值,默认:100,代表含义为AOF文件大小超过上次重写AOF文件的一倍时则进行重写
3.1.7 auto-aof-rewrite-min-size
设置重写规则(下面会讲到rewrite)的文件大小基准值,默认:64mb,代表含义为AOF文件大小超过64mb则进行重写
3.1.8 aof-load-truncated
在Redis过程中,可能会发现AOF文件在末尾被截断的情况。如果aof load truncated设置为yes,则加载并删除一个截断的aof文件,Redis服务器会发出一个日志来通知用户该事件。否则,如果该选项设置为“否”,则服务器将中止并返回一个错误。当选项设置为“否”时,用户需要在重新启动之前,使用“redis check AOF”实用程序修复AOF文件。如果在加载过程中发现AOF文件已损坏,那么服务器仍将退出并出现错误。默认:yes
3.2 AOF修复
运行根目录下redis-check-aof --fix进行修复
3.3 AOF恢复
将appendonly.aof文件移动到redis根目录并启动服务
3.4 Rewrite重写机制
3.4.1 Rewrite是什么
AOF采用文件追加的方式,会导致文件越来越大,为了避免出现此种情况,新增了持久化重写机制,当AOF文件大小超过了所设定的阈值,redis就会启用AOF的文件压缩,使得AOF文件只保留可以恢复数据的最小指令集,客户端可以使用bgrewriteaof命令来启动AOF重写
3.4.2 重写原理
随着AOF文件持续增长过大时,redis会fork 出一条新进程来将文件重写(也是先写临时文件最后rename ) , 遍历新进程的内存中数据,每条记录有一条的 Set 语句。重写 aof 文件的操作,并没有读取旧的 aof 文件,而是将整个内存中的数据内容用命令的方式重写了一个新的 aof 文件。
3.4.3 触发机制
redis会记录上次重写时AOF文件的大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大小大于64M时触发。也就是上文3.1.6、3.1.7的auto-aof-rewrite-percentage和auto-aof-rewrite-min-size参数
3.5 AOF的优势
(1)使用AOF可以设置不同的fsync策略:完全不fsync,每秒fsync,每次查询fsync。使用fsync every second的默认策略,对于服务器执行写操作依旧可以保持不错的性能(fsync是使用后台线程执行的,当没有fsync进行时,主线程将努力执行写操作),但是您可能损失1秒的写操作。
(2)AOF日志是一个只附加的日志,因此在断电的情况下没有查找和损坏问题。即使由于某种原因(磁盘已满或其他原因)日志以半写命令结束,redis check aof工具也能够轻松地修复它。
(3)Redis能够在后台自动重写AOF。重写是完全安全的,因为当Redis继续附加到旧文件时,用创建当前数据集所需的最小操作集生成一个完全新的文件,并且一旦第二个文件准备就绪,Redis就会切换这两个文件并开始附加到新文件。
(4)AOF以易于理解和解析的格式存储了每个写操作日志记录,可以轻松导出AOF文件。例如,即使您不小心用FLUSHALL命令刷新了所有内容,只要在此期间没有重写日志,您仍然可以通过停止服务器、删除最新命令并重新启动Redis来保存数据集。
3.6 AOF的劣势
(1)对于相同的数据集,AOF文件通常比等效的RDB文件大。
(2)AOF可能比RDB慢,具体取决于fsync策略。一般来说,fsync设置为每秒一次时,性能仍然非常高,禁用fsync时,即使在高负载下,它也应该与RDB一样快。
(3)在使用AOF时可能遇到十分罕见的错误(几乎可忽略不计),使用RDB持久性几乎不可能出现这种错误。