[转帖]Redis 运维实战 第05期:RDB 持久化

redis,实战,rdb,持久 · 浏览次数 : 0

小编点评

**AOF 和 Redis 的持久化方法比较** | 特征 | AOF | Redis RDB 文件 | |---|---|---| | 数据恢复效率 | 非常慢 | 快速 | | 可靠性 | 低 | 中等 | | 备份方式 |逐条执行 | 存储内存快照 | | 备份时间 | 非常长 | 相对较短 | | 可用性 | 高 | 低 | **混合使用 AOF 日志和内存快照** * 当数据不能丢失时,使用内存快照和 AOF 的混合方法。 * 优先使用 everysec 的配置选项,因为其介于可靠性和性能之间。 * 当从实例需要进行备份时,优先考虑在从实例上进行备份。 **其他补充** * RDB 文件损坏检测可以使用 `redis-check-rdb` 进行检测。 * 单机多实例的 RDB 备份可以使用脚本结合定时任务触发 bgsave 进行进行。

正文

https://cloud.tencent.com/developer/article/1986826

 

前面一节,我们聊了 AOF,AOF 有个不足点就是:进行数据恢复时,需要逐一把日志都执行一遍,非常耗时间。

Redis 还有另外一种持久化方法:内存快照。指内存中的数据在某一时刻的状态记录,这个快照文件就是 RDB(Redis DataBase) 文件。

1 生成 RDB 的方式

两个命令可以生成 RDB 文件:save 和 bgsave

  • save:在主线程中执行,会导致阻塞,线上环境不建议使用
  • bgsave:创建一个子进程,专门用于写入 RDB 文件,避免了主线程的阻塞,这也是 Redis RDB 文件生成的默认配置。

bgsave 为了保证快照完整性,这期间只能处理读操作,Redis 借助操作系统提供的写时复制技术(Copy-On-Write,COW),在执行快照的同时,能正常处理写请求。

写时复制技术: 如果主线程要修改一块数据,那么,这块数据就会被复制一份,生成该数据的副本。然后 bgsave 子进程会把这个副本写入 RDB 文件,而这个过程中,主线程仍然可以直接修改原来的数据。

在测试实例上执行 bgsave

确定是否执行成功可以执行

info Persistence

这里解释一下几个跟 RDB 相关的参数

  • rdb_changes_since_last_save:自上次 RDB 后,Redis 数据的改动条数
  • rdb_bgsave_in_progress:bgsave 是否在进行中,0 否,1 是
  • rdb_last_save_time:上次 bgsave 的时间戳
  • rdb_last_bgsave_status:上次 bgsave 的状态
  • rdb_last_bgsave_time_sec:上次 bgsave 的持续时间
  • rdb_current_bgsave_time_sec:正在执行的 bgsave 耗时,如果没有正在执行的,则为 -1
  • rdb_last_cow_size:上次 RDB 过程中父进程与子进程相比执行了多少修改

根据 rdb_bgsave_in_progress 这一项为 0,可以判断在执行 info Persistence 命令时,bgsave 已经执行完成了。

除了通过命令的方式触发 RDB 持久化之外,Redis 内部还有自动触发 RDB 的机制。比如以下场景:

  • 配置文件中增加了类似 "save m n" 的配置,表示 m 秒内有 n 次修改则自动触发 bgsave。
  • 新建立 Redis 主从复制时,主节点会执行一次 bgsave 保存 RDB 文件到本地,然后发送给从节点。
  • 执行 shutdown 时,如果没有开启 AOF 则自动执行 bgsave

2 频繁执行全量快照的影响

如果频繁执行全量快照,会带来两方面的开销:

  • 频繁将全量数据写入磁盘,会给磁盘带来很大压力,可能出现前面的没做完,后面的又开始了。导致恶性循环。
  • bgsave 子进程需要通过 fork 操作从主线程创建出来,虽然,子进程在创建后不在会阻塞主线程,但是,fork这个创建过程本身会阻塞主线程,而且主线程内存越大,阻塞时间越长。

3 运维技巧

3.1 RDB 所在分区磁盘满了怎么办

当遇到 RDB 所在分区磁盘满了,可以临时修改 RDB 路径,操作如下:

config set dir /*/*

/*/* 表示还有空间的其他分区下的文件夹

3.2 开启 RDB 压缩

Redis 支持对 RDB 进行压缩,参数为 rdbcompression,设置为 yes 表示开启(默认开启的)。压缩不但可以节省磁盘空间,在创建主从时,也能更快的将全量备份传给从实例,因此建议开启压缩功能。

3.3 RDB 文件损坏检测

当发现 Reids RDB 文件损坏时,可以使用 redis-check-rdb 进行检测,用法如下:

根据上图,说明 RDB 文件中 'memtier-2367894' 这个 key 存在问题。

3.4 单机多实例的 RDB 备份

有些情况,我们会在单台服务器上部署多个 Redis 实例,但是使用配置文件中增加 save 的方式又怕几个实例 RDB 时间冲突,从而影响落盘速度。这种情况,可以使用脚本结合定时任务触发 bgsave 进行 RDB 备份。这样,同机器不同实例的 RDB 备份时间可以自定义错开,防止 IO 跑满带来的问题。

4 备份建议

那么 Redis 究竟怎么备份更好呢?

RDB 尽管恢复会快很多,但是可靠性比 AOF 低,但是如果只使用 AOF,又会存在恢复慢的问题,因此,Redis 4.0 提出了混合使用 AOF 日志和内存快照的方法。

因此对于 Redis 的备份,建议如下:

  • 数据不能丢失时,内存快照和 AOF 的混合使用是一个很好的选择
  • 如果允许分钟级别的数据丢失,可以只使用 RDB
  • 如果只用 AOF ,优先使用 everysec 的配置选项,因为其介于可靠性和性能之间。

当然,如果有从实例,也优先考虑在从实例上进行备份。

与[转帖]Redis 运维实战 第05期:RDB 持久化相似的内容:

[转帖]Redis 运维实战 第05期:RDB 持久化

https://cloud.tencent.com/developer/article/1986826 前面一节,我们聊了 AOF,AOF 有个不足点就是:进行数据恢复时,需要逐一把日志都执行一遍,非常耗时间。 Redis 还有另外一种持久化方法:内存快照。指内存中的数据在某一时刻的状态记录,这个快

[转帖]Redis 运维实战 第09期:Redis 规范

https://cloud.tencent.com/developer/article/1986835 这是专栏《Redis 运维实战》的最后一篇,感谢您的阅读。也感谢 9 篇文章的审稿人:无为,提出了多个修改建议,让文章内容更全面。 由于能力有限,系列文章难免会存在错误或者遗漏,如果您有任何建议,

[转帖]Redis 运维实战 第08期:监控

https://cloud.tencent.com/developer/article/1986832 Redis 在很多互联网公司都充当着非常核心的角色,因此,监控 Redis 以保证其稳定显得格外重要。这节内容就来聊聊 Redis 的一些常见监控项。 1 连接检测 连接失败检测:当监控组件无法连

[转帖]Redis 运维实战 第07期:Hotkey

https://cloud.tencent.com/developer/article/1986830 上一节,我们聊到了 Redis 的 Bigkey,这节内容我们聊聊同样需要引起重视的 Hotkey。 1 背景 Hotkey 指某个时间段访问频率比较高的键值,对应的业务比如热点话题或者热点商品。

[转帖]Redis 运维实战 第06期:Bigkey

https://cloud.tencent.com/developer/article/1986828 1 什么是 Bigkey 下面这两种情况,在很多互联网公司都被认为是 Bigkey: 字符串类型:一般认为超过 10 KB 就是 Bigkey 非字符串类型:哈希、列表、集合、有序集合,体现在元素

[转帖]Redis 运维实战 第04期:AOF 持久化

Redis 运维实战 第04期:AOF 持久化 https://cloud.tencent.com/developer/article/1986824 Redis 有两种持久化方式:AOF 和 RDB。本节就先来聊聊 AOF。 AOF(Append Only File) 日志是写后日志,Redis

[转帖]Redis 运维实战 第02期:Redis Cluster

https://cloud.tencent.com/developer/article/1986819 Redis 最为突出的特性就是:执行命令的速度非常快(原因是所有数据都存放在内存中)。但是单机 Redis 总会遇到瓶颈的,比如:并发、流量、内存等。在 Redis 3.0 之前,官方并没有提供集

[转帖]Redis 运维实战 第01期:Redis 复制

https://cloud.tencent.com/developer/article/1986816 作者简介 马听,多年 DBA 实战经验,对 MySQL、 Redis、ClickHouse 等数据库有一定了解,专栏《一线数据库工程师带你深入理解 MySQL》作者。 从这篇文章开始,将出几期 R

[转帖]Redis学习四(运维指南).

阅读目录 一、上线规划 二、常见运维操作 三、测试方法 回到顶部 一、上线规划 一般 redis 的参数配置都在 redis.conf 中,在上线前根据实际环境配置好合适参数,能有效提高 redis 的可用性。 redis 的运行机器 CPU 不求核数多,但求主频高,Cache大,因为 redis

[转帖]Redis大集群扩容性能优化实践

https://www.jianshu.com/p/1f5d2abbee7f 一、背景 在现网环境,一些使用Redis集群的业务随着业务量的上涨,往往需要进行节点扩容操作。 之前有了解到运维同学对一些节点数比较大的Redis集群进行扩容操作后,业务侧反映集群性能下降,具体表现在访问时延增长明显。 某