https://cloud.tencent.com/developer/article/1986826
前面一节,我们聊了 AOF,AOF 有个不足点就是:进行数据恢复时,需要逐一把日志都执行一遍,非常耗时间。
Redis 还有另外一种持久化方法:内存快照。指内存中的数据在某一时刻的状态记录,这个快照文件就是 RDB(Redis DataBase) 文件。
两个命令可以生成 RDB 文件:save 和 bgsave
bgsave 为了保证快照完整性,这期间只能处理读操作,Redis 借助操作系统提供的写时复制技术(Copy-On-Write,COW),在执行快照的同时,能正常处理写请求。
写时复制技术: 如果主线程要修改一块数据,那么,这块数据就会被复制一份,生成该数据的副本。然后 bgsave 子进程会把这个副本写入 RDB 文件,而这个过程中,主线程仍然可以直接修改原来的数据。
在测试实例上执行 bgsave
确定是否执行成功可以执行
info Persistence
这里解释一下几个跟 RDB 相关的参数
根据 rdb_bgsave_in_progress 这一项为 0,可以判断在执行 info Persistence 命令时,bgsave 已经执行完成了。
除了通过命令的方式触发 RDB 持久化之外,Redis 内部还有自动触发 RDB 的机制。比如以下场景:
如果频繁执行全量快照,会带来两方面的开销:
当遇到 RDB 所在分区磁盘满了,可以临时修改 RDB 路径,操作如下:
config set dir /*/*
/*/* 表示还有空间的其他分区下的文件夹
Redis 支持对 RDB 进行压缩,参数为 rdbcompression,设置为 yes 表示开启(默认开启的)。压缩不但可以节省磁盘空间,在创建主从时,也能更快的将全量备份传给从实例,因此建议开启压缩功能。
当发现 Reids RDB 文件损坏时,可以使用 redis-check-rdb 进行检测,用法如下:
根据上图,说明 RDB 文件中 'memtier-2367894' 这个 key 存在问题。
有些情况,我们会在单台服务器上部署多个 Redis 实例,但是使用配置文件中增加 save 的方式又怕几个实例 RDB 时间冲突,从而影响落盘速度。这种情况,可以使用脚本结合定时任务触发 bgsave 进行 RDB 备份。这样,同机器不同实例的 RDB 备份时间可以自定义错开,防止 IO 跑满带来的问题。
那么 Redis 究竟怎么备份更好呢?
RDB 尽管恢复会快很多,但是可靠性比 AOF 低,但是如果只使用 AOF,又会存在恢复慢的问题,因此,Redis 4.0 提出了混合使用 AOF 日志和内存快照的方法。
因此对于 Redis 的备份,建议如下:
当然,如果有从实例,也优先考虑在从实例上进行备份。