Redis持久化
Redis是内存数据库,如果不将内存中的数据库状态保存到磁盘,一旦服务器进程退出,数据库状态将丢失,
RDB (Redis DataBase)
在指定时间间隔内,将内存中的数据集快照写入磁盘,也就是快照,恢复时直接将快照文件读到内存里
会单独创建一个子进程来进行持久化(fork作用是复制一个与当前进程相同的进程,这是个全新的进程,作为原来进程的子进程)
先将数据写入一个临时文件,等持久化过程都结束了,再用这个临时文件替换上次持久化好的文件,整个过程主进程不进行IO操作,确保及高性能
唯一缺点是最后一次持久化的数据可能丢失
rdb保存的文件是dump.rdb(根据配置文件)
触发机制
- 当配置文件中的save 条件满足时
- 执行flushAll命令时,但里面是空的,无意义
- 退出redis时
如何恢复RDB文件
只需将文件放入redis启动目录(/usr/local/bin),reids启动时会自动检查dump.rdb,并恢复其中数据
优点:
- 适合大规模数据的恢复
- 对数据的完整性要求不高时适用
缺点:
- 如果redis意外宕机了,最后一次修改的数据将会丢失
- fork进程时,需占用内存空间
AOF (Append Only File)
如要使用,先在配置文件中开启
以日志的形式将所有的命令都记录下来(读数据操作不记录),恢复时,将这个文件全部执行一遍
AOF保存的文件名为appendonly.aof
如果AOF文件遭到破坏,redis是启动不起来的
redis提供了工具可以修复aof文件
执行以下命令即可
redis-check-aof --fix appendonly.aof
文件正常之后,重启就可以恢复了
缺点:
- 相对于数据文件来说,aof远远大于rdb,修复速度也比rdb慢
- 运行效率也比rdb慢
优点:
文件完整性会更好(当然这取决于配置文件中的配置)
# appendfsync always # 每次修改都会同步,效率太低
appendfsync everysec # 每一秒同步一次,可能会丢失这一秒的数据
# appendfsync no # 不同步,操作系统自己同步数据,速度最快
扩展:
重写原理
- AOF 文件持续增长而过大时,会 Fork 出一条新进程来将文件重写(也是先写临时文件最后再 rename)。
- 遍历新进程的内存中数据,每条记录有一条的 set 语句。
- 重写 aof 文件的操作,并没有读取旧的 aof 文件,这点和快照有点类似。
aof默认是文件的无限累加,文件越来越大,所以设置了重写机制
auto-aof-rewrite-min-size 64mb # 默认是文件大小达到64兆,重写到新文件
如果同时开启两种持久化方式,重启redis默认会先载入aof。因为aof数据集要比rdb更加完整,而且rdb不实时,所以rdb更适合用于备份数据库(aof不断变化不好备份)