Redis持久化
Redis是内存数据库,如果不将内存中的数据库状态保存到磁盘,那么一旦服务器进程退出,服务器中的数据库状态也会消失,所以redis提供了持久化功能
- RDB:在指定的时间间隔内将内存中的数据集快照写入磁盘,它恢复时是将快照文件直接读到内存里。Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOP方式更加高效。RDB的缺点是最后一次持久化后的数据可能丢失。Redis默认的就是RDB,一般情况下不需要修改这个配置。RDB保存的文件是dump.rdb文件,都是在配置文件的快照中进行配置
- AOP:将所有的命令都记录下来,恢复的时候把这个文件全部在执行一遍,以日志的形式来记录每个写操作,将redis执行过的所有记录记录下来(读操作不记录),只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。Aof保存的是appendonly.aof文件,在配置文件中进行配置,默认是不开启的,需要手动进行配置appendonly yes
RDB
RDB触发机制:
- save的规则满足的情况下,会自动触发rdb规则
- 执行flushall命令,会触发rdb规则
- 退出redis,会产生rdb文件
如何恢复RDB文件:
- 只需要将rdb文件放入到redis启动目录就可以,redis启动的时候会自动检查dump.rdb,恢复其中的数据
- 查看需要存在的位置
config get dir --查看文件需要存在的位置,返回/usr/local/bin,表示如果这个路径下存在dump.rdb文件,启动就会自动恢复其中的数据
- rdb自己的默认配置就够用了,使用的时候几乎不用动
优点:
- 适合大规模的数据恢复
- 如果对数据的完整性要求不高
缺点:
- 需要一定的时间间隔进行操作,如果redis意外宕机了,最后一次修改数据就没有了
- fork进程的时候,会占用一定的内存空间
AOF
AO触发机制:
- 将每一个写操作记录到文件中
如果aof文件有错误,这时候redis是启动不起来的,我们需要修复这个aof文件,redis给我们提供了一个工具:redis-check-aof --fix appendonly.aof
优点:
- 每一次修改都同步,文件的完整性更好
- 默认开启的是每秒同步一次,可能会丢失一秒的数据
- 从不同步,效率最高
缺点:
- 相对于数据文件来说,aof大小远远大于rdb,修复的速度也要远远大于rdb
- aof运行效率也要比rdb慢,所以redis默认开启的是rdb
重写规则说明:如果aof文件大于64m,太大了,fork一个新的进程来将文件进行重写
扩展
- RDB持久化方式能够在指定的时间间隔内对你的数据进行快照存储
- AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以Redis协议追加保存每次写的操作到文件末尾,Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
- 只做缓存,如果只希望数据在服务器运行的时候存在,也可以不使用任何持久化
- 同时开启两种持久化方式:在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集完整;RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件
- 至于要不要使用aof,建议不要,因为RDB更适合用于备份数据库(AOF在不断变化不好备份),快速重启,而且不会有AOF可能潜在的BUG
- 性能上:RDB文件只能作后备用途,建议在slave上持久化RDB文件,而且只要15分钟备份一次就够了,只保留save 900 1 这条规则;如果开启aof,好处是在恶劣环境下只会丢失不超过2秒数据,启动脚本较简单值load自己的aof文件即可,代价一是带来了持续的io,二是aof rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞集合是不可避免的,只要硬盘许可,应该尽量减少AOF rewirte的频率,AOF重写的基础大小默认是64M,太小了,可以设到5G以上,默认超过原大小100%大小重写可以改到适当的数值;如果不开启aof,仅靠主从复制实现高可用性也可以,能省掉一大笔io,也减少了rewrite时带来的系统波动,代价是如果主机从机都宕机了,会丢失十几分钟的数据,启动脚本也要比较两个主从机的RDB文件,载入新的那个