RDB(Redis DataBase)
1、RDB是什么?
在指定的时间间隔内将内存中的数据快照写入磁盘。
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程不进行任何IO操作,保证了极高的性能。
如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加高效。
RDB的缺点是最后一次持久化后的数据可能丢失。
2、fork的含义
fork的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等)数值都和原进程一样,但是是一个全新的进程,并作为原进程的子进程。
3、RDB保存的是dump.rdb文件
4、如何配置
https://blog.csdn.net/qq_37054755/article/details/117484230
5、如何触发RDB快照
- 配置文件中默认地快照配置
- 命令save或者是bgsave
· save,主进程阻塞,保存快照
· bgsave,fork主进程的子进程完成保存快照的任务,异步行动。 - 执行flushall命令,也会产生dump.rdb文件,但里面是空的,无意义
6、优势
- 适合大规模的数据恢复
- 对数据完整性和一致性要求不高
7、劣势
- 隔一段时间做一次备份,所以如果redis意外down掉的话,就会丢失最后一次快照后的所有修改
- FORK的时候,内存中的数据被克隆了一份,大致两倍的膨胀性需要考虑。
8、如何停止
- 动态停止RDB保存的方法:
redis-cli config set save ""
AOF(Append Only File)
1、是什么
以日志的形式来记录每个写操作,将redis执行过的所有写指令记录下来(读操作不记录),只追加文件但不可以改写文件,redis启动之初会读取该文件并重新构建数据。
2、如何配置
https://blog.csdn.net/qq_37054755/article/details/117484230
3、AOF启动/修复/恢复
- 正常恢复:
启动:修改默认地appendonly no,改为yes
将原有数据aof文件复制一份保持到对应目录
恢复:重启redis然后重新加载 - 异常恢复:
备份被写坏的AOF文件
修复:redis-check-aof --fix 进行修复
恢复:重启redis然后重新加载
4、rewrite(重要)
- 是什么:AOF采用文件追加方式,文件会越来越大,为避免出现此种情况,新增了重写机制。当AOF文件的大小超过所设定的阈值时,redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集。使用的命令是:
bgrewriteaof
- 重写原理:AOF文件持续增长过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename),遍历新进程中内存的数据,每条记录有一条set语句。重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似
- 触发机制:redis会记录上次重写时的AOF大小,默认配置是当aof文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
5、优势
- 每秒同步:appendfsync everysec 异步操作,每秒记录,如果一秒内宕机,有数据丢失
- 每修改同步:appendfsync always 同步持久化,每次发生数据变更会立即记录到磁盘,性能较差但数据完整性比较好
- 不同步:appendfsync no,看操作系统心情
6、劣势
- 相同数据集的数据而言,aof文件要远大于rdb文件,恢复速度慢于rdb
- aof运行效率要慢于rdb,每秒同步策略效率较好但仍慢于rdb,不同步效率和rdb相同
如何选择
- RDB持久化方式能够在指定的时间间隔内对你的数据进行快照存储
- AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾,redis还能对aof文件进行后台重写,使得aof文件的体积不至于过大。
- 只做缓存:如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式。
- 当同时使用两种持久化方式:在这种情况下,当redis重启的时候会优先载入aof文件来恢复原始的数据,因为通常情况下aof文件保存的数据更加完整。rdb数据不实时,同时使用两者时服务器重启也会只找aof,那可不可以只用aof呢,作者建议不要,因为rdb更适合用于备份数据库,快速重启,而且不会有aof可能潜在的bug。