Redis持久化配置

最新推荐文章于 2024-08-27 11:41:43 发布

weixin_43315211

最新推荐文章于 2024-08-27 11:41:43 发布

阅读量196

点赞数

CC 4.0 BY-SA版权

分类专栏： redis 文章标签： redis 持久化

本文链接：https://blog.youkuaiyun.com/weixin_43315211/article/details/89465441

redis 专栏收录该内容

4 篇文章

订阅专栏

一、RDB（Redis Database）

1、RDB持久化的四种形式：

a) 满足配置文件中的配置参数，自动进行bgsave（打开子进程，异步）操作。
b) 客户端手动执行save（阻塞，其他操作等待）操作。
c) flushall。产生的rdb文件是空的，没啥意义。
d) shutdown。产生的rdb文件是空的，没啥意义。

2、SAVE 和 BGSAVE 命令

SAVE：
不用创建新的进程，速度略快
适合停机维护，服务低谷时段
BGSAVE：
需要创建子进程，消耗额外的内存
适合线上执行

3、配置文件讲解

more /opt/apps/redis-3.0.0/redis.conf
    37 daemonize no    #####是否在后台运行，安装时应将此处改为“daemonize yes”
    45 port 6379    #####redis默认监听的端口为6379
    140 #   save ""    #####注销142/143/144，打开本行，则等同于关闭rdb持久化
    141 
    142 save 900 1    #####在15分钟内，有1个写操作，则进行持久化
    143 save 300 10    #####在5分钟内，有10个写操作，则进行持久化
    144 save 60 10000    #####在1分钟内，有10000个写操作，则进行持久化
注：
    
    159 stop-writes-on-bgsave-error yes    #####如果生成rdb可能出错，就禁止写入新数据。如果改成no,就可能造成数据的不一致。
    165 rdbcompression yes    #####是否采用压缩。默认采用LZF的压缩格式。
    174 rdbchecksum yes    #####rdb文件生成后，是否检查校验和。大概会消增加10%的性能消耗。
    177 dbfilename dump.rdb    #####生成的rdb文件的名称
    187 dir ./    #####在当前路径生成rdb文件

4、禁用rdb持久化策略

方法一：
修改配置文件140/142/143/144
方法二：
redis-cli config set save “”

5、RDB优劣与生产环境应用

优点：
完全备份，不同时间的数据集备份可以做到多版本恢复
紧凑的单一文件，方便网络传输，适合灾难恢复
恢复大数据集速度较AOF快

缺点：
会丢失最近写入、修改的而未能持久化的数据
fork过程非常耗时，会造成毫秒级不能响应客户端请求

生产环境应用：
创建一个定时任务crontab job，每小时或者每天将dump.rdb复制到指定目录
确保备份文件名称带有日期时间信息，便于管理和还原对应的时间点的快照

二、AOF（Append Only File）

1、基础知识

a) Redis 默认不开启。如果启用，则优先使用aof恢复数据库。
b) 采用日志的形式来记录每个写操作，并追加到文件中。
c) Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
d) flushall/flushdb 操作也会写入aof文件中，如果关闭数据库前最后执行了这两个操作，要恢复数据必须在启动前先去aof文尾部删除这两个操作。

2、AOF机制剖析

a) AOF方式不能保证绝对不丢失数据的原因：
目前常见的操作系统中，执行系统调用write函数，将一些内容写入到某个文件里面时，为了提高效率，系统通常不会直接将内容写入硬盘里面，而是先将内容放入一个内存缓冲区（buffer）里面，等到缓冲区被填满，或者用户执行fsync调用和fdatasync调用时才将储存在缓冲区里的内容真正的写入到硬盘里，未写入磁盘之前，数据可能会丢失。

b) 写入磁盘的策略

appendfsync选项，这个选项的值可以是always、everysec或者no。
always：服务器每写入一个命令，就调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，也不会丢失任何已经成功执行的命令数据
everysec（默认）：服务器每一秒重调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，最多只丢失一秒钟内的执行的命令数据
no：服务器不主动调用fdatasync，由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下，服务器遭遇意外停机时，丢失命令的数量是不确定的
运行速度：always的速度慢，everysec和no都很快

3、AOF重写机制

(1) 原因：
AOF文件过大
合并重复的操作，AOF会使用尽可能少的命令来记录
(2) AOF重写的两种形式
手动：客户端向服务器发送BGREWRITEAOF命令
自动：配置文件中的选项，自动执行BGREWRITEAOF命令
(3) 过程
- 1、执行AOF重写请求
- 2、父进程执行fork创建子进程，开销等同于bgsave过程
- 3.1、主进程fork操作完成后，继续响应其他命令。所有修改命令依然写入AOF缓冲区，并根据 appendfsync策略同步到磁盘，保证原有AOF机制正确性。
- 3.2、由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应命令，redis使用“AOF重写缓冲区”保存这部分新数据，防止新AOF文件生成期间丢失这部分数据。
- 4、子进程根据内存快照，按照命令合并规则写入到新AOF文件。每次批量写入硬盘数据量由aof-rewrite-incremental-fsync控制，默认是32MB，防止单词刷盘数据过多造成硬盘阻塞。
- 5.1、新AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息。
- 5.2、父进程把AOF重写缓冲区数据写入到新的AOF文件。
- 5.3、使用新AOF文件替换老文件，完成AOF重写。
如果写入操作异常或者aof被恶意篡改，可以使用bin目录下的redis-check-aof工具修复：
执行 “redis-check-aof --fix appendonly.aof” 即可。
该命令会删除aof文件中不符合redis写操作规范的内容。

4、配置文件讲解

more /opt/apps/redis-3.0.0//redis.conf
    501 appendonly no    ####是否开启aof持久化策略
    505 appendfilename "appendonly.aof"    #####aof文件名称
    530 # appendfsync always    #####每次写操作，都将该操作从内存缓冲区写入aof文件
    531 appendfsync everysec    #####每间隔1秒钟将内存缓冲区中的写操作写入aof文件
    532 # appendfsync no    #####有操作系统决定何时将内存缓冲区的写操作写入aof文件
注：
    530/531/532 必背
    553 no-appendfsync-on-rewrite no    #####日志重写时，继续写入日志。改为yes则不继续写入。
            #####如果redis有较大延迟问题，可以将该参数设置为yes。
    572 auto-aof-rewrite-percentage 100    #####在aof文件大小大于auto-aof-rewrite-min-size的情况下，如果超过了上一次重写后aof文件体积的100%，则触发重写。0代表关闭aof重写。
            #####如果服务器刚启动，则以载入的aof文件体积为初始值。
    573 auto-aof-rewrite-min-size 64mb    #####考虑触发aof重写的aof文件最小体积

5、AOF优劣

优点：
写入机制，默认fysnc每秒执行，性能很好不阻塞服务，最多丢失一秒的数据
重写机制，优化AOF文件
如果误操作了（FLUSHALL等），只要AOF未被重写，停止服务移除AOF文件尾部FLUSHALL命令，重启Redis，可以将数据集恢复到 FLUSHALL 执行之前的状态
缺点：
相同数据集，AOF文件体积较RDB大了很多
恢复数据库速度比RDB慢（文本，命令重演）