Redis_持久化

RDB

Redis DataBase

Redis 会单独创建fork一个子进程来进行持久化

• Fork：复制一个与当前进程一样的进程(类似python的os.fork)，新进程的所有数据（变量，环境变量，程序计数器等）和原进程一致，但是是一个全新的进程，并作为原进程的子进程

• 会将数据写入到一个临时文件中，待持久化过程结束，再使用这个临时文件替换上次持久化好的文件
• 整个过程中。主进程不进行任何IO操作，确保了极高的性能
• 如果需要的大规模进行数据的恢复，且对于数据恢复的完整性不是非常敏感，RDB方式比AOF方式更加的高效
• RDB的缺点是最后一次持久化后的数据可能丢失

• 在指定的时间间隔内将内存中的数据集快照写入磁盘
  •  Snapshot 快照 ，恢复时就是将快照文件直接读取到内存中

• RDB 保存的是dump.rdb文件
• flushall：清空内存，快读写入快照，会替换上次的持久化的文件

 

 

 

 

恢复快照

• 将 备份文件dump.rdb 移动到redis安装目录或者配置文件设置的目录，启动服务即可，自动读取
• Config get  dir 获取配置的目录

优点

• 适合大规模的数据恢复
• 对数据性的完整性和一致性要求不高

缺点

• 意外down掉的话，就会丢失最后一次快照后的修改
• Fork 内存数据被克隆一份，2倍的膨胀性

 

Append Only File

以日志的方式   记录每个写操作

• 将Redis所有写指令记录下来
• 只许追加文件，不许改写文件
• redis启动之初会读取该文件重新构建数据

redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

🤮 AOF和RDB可以共存，但是启动服务的时候会使用aof文件，aof文件可以编辑，损坏的情况下可以使用

 

检查aof文件

会删除不识别的命令。
redis-check-aof --fix appendonly.aof

配置位置

appendonly	yes	启用
appendfilename	Appendonly.aof	默认
appendfsync	Always	同步持久化，每次发生变更立即记录到磁盘，性能较差，完整性较好
	Everysec	异步操作，默认设置，每秒记录，如果一秒内宕机，有数据丢失
No-appendfsnc-onwrite

 

 

Rewrite

Aof 采用文件追加的方式，文件越来越大，新增了重写机制

• 当文件大小超过了了设定的阙值时，就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集,可以使用命令 bgrewriteaof
• Redis 记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次Rewrite后大小的一倍且文件大于64M时触发

优点

• 灵活的配置

缺点

• 相同数据集的数据而言，aof文件要远大于rdb，恢复速慢于rdb
• aof运行效率要慢于rdb，每秒同步策略较好，不同步效率和rdb相同

持久化对比

RDB持久化方式能够在指定的时间间隔能对数据进行快照存储

AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大

同时开启两种持久化方式

当Redis重启的时候会优先载入AOF文件恢复原始的数据，通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整

RDB数据不实时，同时使用两个服务器两者的服务器重启也只会找AOF文件

性能建议

RDB文件只用作后备用途，只在Slave上持久化RDB文件，只要15分钟备份一次即可，只保留save 900 1 这条规则

如果EnalbeAOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。

• 代价一是带来了持续的IO，
• 代价二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的：只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100％大小时重写可以改到适当的数值

如果不EnableAOF，仅靠Master-SlaveReplication实现高可用性也可以：能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master／Sve同时倒掉，会丢夫十几分钟的数据，启动脚本也要比较两个Master/引ave中的RDB文件，载入较新的那个：