redis的rdb文件过大 redis的rdb太大

转载

mob6454cc749e02 2023-09-21 07:34:40

一、优势

1.RDB 是一个非常紧凑(compact)的文件，它保存了redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。

2.生成RDB 文件的时候，redis 主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO 操作。

3.RDB 在恢复大数据集时的速度比AOF 的恢复速度要快。

二、劣势

1、RDB 方式数据没办法做到实时持久化/秒级持久化。因为bgsave 每次运行都要执行fork 操作创建子进程，频繁执行成本过高。

2、在一定间隔时间做一次备份，所以如果redis 意外down 掉的话，就会丢失最后一次快照之后的所有修改（数据有丢失）。

如果数据相对来说比较重要，希望将损失降到最小，则可以使用AOF 方式进行持久化。

AOF

Append Only File

AOF：Redis 默认不开启。AOF 采用日志的形式来记录每个写操作，并追加到文件中。开启后，执行更改Redis 数据的命令时，就会把命令写入到AOF 文件中。

Redis 重启时会根据日志文件的内容把写指令从前到后执行一次以完成数据的恢复工作。

AOF 配置

配置文件redis.conf

# 开关
appendonly no
# 文件名
appendfilename "appendonly.aof"

AOF 文件的内容（vim 查看）：

问题：数据都是实时持久化到磁盘吗？

由于操作系统的缓存机制，AOF 数据并没有真正地写入硬盘，而是进入了系统的硬盘缓存。什么时候把缓冲区的内容写入到AOF 文件？

参数	说明
appendfsync everysec	AOF 持久化策略（硬盘缓存到磁盘），默认everysec  no 表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快，但是不太安全；  always 表示每次写入都执行fsync，以保证数据同步到磁盘，效率很低；  everysec 表示每秒执行一次fsync，可能会导致丢失这1s 数据。通常选择everysec ，兼顾安全性和效率。

问题：文件越来越大，怎么办？

由于AOF 持久化是Redis 不断将写命令记录到AOF 文件中，随着Redis 不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及AOF 恢复要求时间越长。

例如set leon 666，执行1000 次，结果都是leon=666。

为了解决这个问题，Redis 新增了重写机制，当AOF 文件的大小超过所设定的阈值时，Redis 就会启动AOF 文件的内容压缩，只保留可以恢复数据的最小指令集。

可以使用命令bgrewriteaof 来重写。

AOF 文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的AOF 文件。

# 重写触发机制
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

参数	说明
auto-aof-rewrite-percentag e	默认值为100。aof 自动重写配置，当目前aof 文件大小超过上一次重写的aof 文件大小的百分之多少进行重写，即当aof 文件增长到一定大小的时候，Redis 能够调用bgrewriteaof 对日志文件进行重写。当前AOF 文件大小是上次日志重写得到AOF 文件大小的二倍（设置为100）时，自动启动新的日志重写过程。
auto-aof-rewrite-min-size	默认64M。设置允许重写的最小aof 文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写。

问题：重写过程中，AOF 文件被更改了怎么办？

另外有两个与AOF 相关的参数：

参数	说明
no-appendfsync-on-rewrite	在aof 重写或者写入rdb 文件的时候，会执行大量IO，此时对于everysec 和always 的aof 模式来说，执行fsync 会造成阻塞过长时间，no-appendfsync-on-rewrite 字段设置为默认设置为no。如果对延迟要求很高的应用，这个字段可以设置为yes，否则还是设置为no，这样对持久化特性来说这是更安全的选择。设置为yes 表示rewrite 期间对新写操作不fsync, 暂时存在内存中,等rewrite 完成后再写入，默认为no，建议修改为yes。Linux 的默认fsync 策略是30 秒。可能丢失30 秒数据。
aof-load-truncated	aof 文件可能在尾部是不完整的，当redis 启动的时候，aof 文件的数据被载入内存。重启可能发生在redis 所在的主机操作系统宕机后，尤其在ext4 文件系统没有加上data=ordered 选项，出现这种现象。redis 宕机或者异常终止不会造成尾部不完整现象，可以选择让redis 退出，或者导入尽可能多的数据。如果选择的是yes，当截断的aof 文件被导入的时候，会自动发布一个log 给客户端然后load。如果是no，用户必须手动redis-check-aof 修复AOF 文件才可以。默认值为yes。