如何快速实现 Redis 持久化

RDB快照(Redis DataBase)

RDB是一种快照存储持久化方式,具体就是将Redis某一时刻的内存数据保存到硬盘的文件当中,默认保存的文件名为dump.rdb,而在Redis服务器启动时,会重新加载dump.rdb文件的数据到内存当中恢复数据。

开启RDB持久化方式

开启RDB持久化方式很简单,客户端可以通过向Redis服务器发送save或bgsave命令让服务器生成rdb文件,或者通过服务器配置文件指定触发RDB条件。每次执行都会将所有redis内存快照到一个新的rdb文件里,并覆盖原有rdb快照文件。

方式一:save命令

# 同步数据到磁盘上
> save 
如何快速实现 Redis 持久化

当客户端向服务器发送save命令请求进行持久化时,服务器会阻塞save命令之后的其他客户端的请求,直到数据同步完成。 如果数据量太大,同步数据会执行很久,而这期间Redis服务器也无法接收其他请求,所以,最好不要在生产环境使用save命令。

方式二:bgsave命令

# 异步保存数据集到磁盘上
> bgsave
如何快速实现 Redis 持久化
  • 当客户端发服务发出bgsave命令时,Redis服务器主进程会forks一个子进程来解决数据同步问题,在将数据保存到rdb文件之后,子进程会退出。
  • 所以,与save命令相比,Redis服务器在处理bgsave采用子线程进行IO写入,而主进程仍然可以接收其他请求,但forks子进程是同步的,所以forks子进程时,一样不能接收其他请求,这意味着,如果forks一个子进程花费的时间太久(一般是很快的),bgsave命令仍然有阻塞其他客户的请求的情况发生。
  • 我们可以控制单个Redis实例的最大内存,来尽可能降低Redis在fork时的事件消耗。以及上面提到的自动触发的频率减少fork次数,或者使用手动触发,根据自己的机制来完成持久化。

方式三:通过配置文件自动触发

自动触发的场景主要是有以下几点:

  • 1.根据我们的 save m n 配置规则自动触发;
  • 2.从节点全量复制时,主节点发送rdb文件给从节点完成复制操作,主节点会触发 bgsave;
  • 3.执行 debug reload 时;
  • 4.执行shutdown时,如果没有开启aof,也会触发。

这里我们讲的是根据配置文件自动触发:

# 时间策略
#关闭RDB只需要将所有的save保存策略注释掉即可
save 900 1   #900s内如果有1条数据写入,就产生RDB快照
save 300 10 #300s内有10条数据写入,就产生RDB快照 
save 60 10000  #60s内如果有10000条数据写入,就产生RDB快照

# 文件名称
dbfilename dump.rdb

# 文件保存路径
dir /var/lib/redis/6379

# 如果持久化出错,主进程是否停止写入
stop-writes-on-bgsave-error yes

# 是否压缩
# 建议没有必要开启,毕竟Redis本身就属于CPU密集型服务器,再开启压缩会带来更多的CPU消耗,相比硬盘成本,CPU更值钱。
rdbcompression no

# 导入时是否检查
rdbchecksum yes

save和bgsave对比

如何快速实现 Redis 持久化

配置文件自动生成rdb文件后台使用的是bgsave方式。

RDB文件

前面介绍了三种让服务器生成rdb文件的方式,无论是由主进程生成还是子进程来生成,其过程如下:

  • 生成临时rdb文件,并写入数据。
  • 完成数据写入,用临时文件替代正式rdb文件。
  • 删除原来的db文件。

COW写时复制(copy-on-write)

fork创建出的子进程,与父进程共享内存空间。也就是说,如果子进程不对内存空间进行写入操作的话(Redis的子进程只做数据落盘的操作,也不会去写数据),内存空间中的数据并不会复制给子进程,这样创建子进程的速度就很快了!(不用复制,直接引用父进程的物理空间,玩的是指针)。

如何快速实现 Redis 持久化

当Redis父进程修改数据时,父进程会将原先的数据复制一份生成新的副本,然后修改父进程的指针,指向新的数据,此时父进程修改的新的数据不会影响到子进程。此时子进程的指针仍然指向旧的数据,子进程看到的数据还是bgsave时候的数据。当下一次执行bgsave时,新fork出来的子进程指针才会指向这次新的数据。

如何快速实现 Redis 持久化

AOF(append-only file)

与RDB存储某个时刻的快照不同,AOF持久化方式会记录客户端对服务器的每一次写操作命令,并将这些写操作以追加的方式保存到以后缀为aof文件中,在Redis服务器重启时,会加载并运行aof文件的命令,以达到恢复数据的目的。

开启AOF持久化的方式

方式一:bgrewriteaof命令

> bgrewriteaof

方式二:通过配置文件自动触发

Redis默认不开启AOF持久化方式,我们可以在配置文件中开启并进行更加详细的配置:

#开启aof
appendonly yes

# 文件名称
appendfilename "appendonly.aof"

# 同步方式
#appendfsync always #每次有新命令追加到 AOF 文件时就执行一次 fsync ,非常慢,也非常安全。 
appendfsync everysec #默认方式,每秒 fsync 一次,足够快,并且在故障时只会丢失 1 秒钟的数据。
#appendfsync no  #从不 fsync ,将数据交给操作系统来处理。更快,也更不安全的选择。

重写

AOF将客户端的每一个写操作都追加到aof文件末尾,比如对一个key多次执行incr命令,这时候,aof保存每一次命令到aof文件中,aof文件会变得非常大。

127.0.0.1:6379> INCR readcount
(integer) 1
127.0.0.1:6379> INCR readcount
(integer) 2
127.0.0.1:6379> INCR readcount
(integer) 3
127.0.0.1:6379> INCR readcount
(integer) 4
127.0.0.1:6379> INCR readcount
(integer) 5

这是一种resp协议格式数据,星号后面的数字代表命令有多少个参数,$号后面的数字代表这个参数有几个字符

[root@redis 6379]# cat appendonly.aof
*2
$6
SELECT
$1
0
*2
$4
INCR
$9
readcount
*2
$4
INCR
$9
readcount
*2
$4
INCR
$9
readcount
*2
$4
INCR
$9
readcount
*2
$4
INCR
$9
readcount

手动执行重写命令BGREWRITEAOF:

127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started

重写后AOF文件里如下,将多个incr命令进行了合并

[root@redis 6379]# cat appendonly.aof
*2
$6
SELECT
$1
0
*3
$3
SET
$9
readcount
$1
5

重写配置参数

AOF重写redis会fork出一个子进程去做(与bgsave命令类似),不会对redis正常命令处理有太多影响:

auto‐aof‐rewrite‐min‐size 64mb #aof文件至少要达到64M才会自动重写,文件太小恢复速度本来就 很快,重写的意义不大
auto‐aof‐rewrite‐percentage 100 #aof文件自上一次重写后文件大小增长了100%则再次触发重写,例如上一次重写的大小是64M,那么下一次达到128M再做重写

AOF重写流程图

如何快速实现 Redis 持久化
  • 在重写期间,由于主进程依然在响应命令,为了保证最终备份的完整性;因此它依然会写入旧的AOF file中,如果重写失败,能够保证数据不丢失。
  • 为了把重写期间响应的写入信息也写入到新的文件中,因此也会为子进程保留一个buf,防止新写的file丢失数据。
  • 重写是直接把当前内存的数据生成对应命令,并不需要读取老的AOF文件进行分析、命令合并。
  • 不管是RDB还是AOF都是先写入一个临时文件,然后通过 rename 完成文件的替换工作。

混合持久化

重启 Redis 时,我们很少使用 RDB来恢复内存状态,因为会丢失大量数据。我们通常使用 AOF 日志重放,但是重放 AOF 日志性能相对 RDB来说要慢很多,这样在 Redis 实例很大的情况下,启动需要花费很长的时间。Redis 4.0 为了解决这个问题,带来了一个新的持久化选项——混合持久化。通过如下配置可以开启混合持久化(前提必须先开启aof):

aof‐use‐rdb‐preambleyes #开启混合持久化

如果开启了混合持久化,AOF在重写时,不再是单纯将内存数据转换为RESP命令写入AOF文件,而是将重写这一刻之前的内存做RDB快照处理,并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起,都写入新的AOF文件,新的文件一开始不叫appendonly.aof,等到重写完新的AOF文件才会进行改名,覆盖原有的AOF文件,完成新旧两个AOF文件的替换。于是在 Redis 重启的时候,可以先加载 RDB 的内容,然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放,因此重启效率大幅得到提升。

127.0.0.1:6379> set k 1
OK
127.0.0.1:6379> set k 2
OK
127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started

查看此时的appendonly.aof文件:此时存放的是RDB的内容

[root@redis 6379]# cat appendonly.aof
REDIS0009� redis-ver5.0.7�
�edis-bits�@�ctime�%y�_used-mem��
 aof-preamble���k� readcount�� R��i9$�[root@redis 6379]#

如果新增加了数据:

127.0.0.1:6379> set k 3
OK

那么新的数据会以为RESP命令的方式追加在后面:

[root@redis 6379]# cat appendonly.aof
REDIS0009� redis-ver5.0.7�
�edis-bits�@�ctime�%y�_used-mem��
 aof-preamble���k� readcount�� R��i9$�*2
$6
SELECT
$1
0
*3
$3
set
$1
k
$1
3

混合持久化AOF文件结构如下:

如何快速实现 Redis 持久化

从持久化中恢复数据

数据的备份、持久化做完了,我们如何从这些持久化文件中恢复数据呢?如果一台服务器上有既有RDB文件,又有AOF文件,该加载谁呢?

其实想要从这些文件中恢复数据,只需要重新启动Redis即可。我们还是通过图来了解这个流程:

如何快速实现 Redis 持久化

启动时会先检查AOF文件是否存在,如果不存在就尝试加载RDB。那么为什么会优先加载AOF呢?因为AOF保存的数据更完整,通过上面的分析我们知道AOF基本上最多损失1s的数据。

文章来源:https://www.cnaaa.net,转载请注明出处:https://www.cnaaa.net/archives/9105

(0)
杰斯的头像杰斯
上一篇 2023年6月29日 下午4:45
下一篇 2023年7月13日 下午4:15

相关推荐

  • Sql Server2005 如何导出数据库数据

    Sql Server2005数据库数据导出两种方式 第一种,数据库数据直接备份,右键点击需要备份的库,打开任务,打开备份,然后记一下数据库备份文件位置,直接点击确定即可成功,注意修改文件路径可能会提示文件无权限 第二种方式 打开本地服务,停止Sql server服务,然后去复制需要的ldf与mdf文件

    2022年12月16日
    41400
  • mysql误删数据后,从binlog中进行恢复删除数据

    从mysql的logbin中恢复误删数据在一次数据维护过程中,对数据删除时没有提前备份数据,导致数据被删除后无法通过备份文件直接恢复。 1.查找当前操作的binlog状态在myql命令行或者链接工具中,命令查看binlog当前的位置状态和文件信息。 2.flush logs刷新状态 在myql命令行或者链接工具中,使用flush logs命令重新生成新的bi…

    2023年7月29日
    32800
  • MySQL 如何避免克隆失败后再次初始化

    在我之前关于 CLONE INSTANCE 命令的博客文章《MySQL 克隆插件不是你的备份》中,我提到使用选项 DATA DIRECTORY 有助于避免在克隆操作失败时需要从头开始重新初始化副本和克隆相关设置的情况。 MySQL 克隆插件简化了新副本的配置,但不会简化失败后的服务器恢复,除非您准备从头开始重新安装 M…

    2023年10月23日
    33400
  • SQL Server 2008 R2双机热备之发布、订阅实现实时同步实践过程

    一、复制的功能概述          SQL Server 复制功能实现了主从库的读写分离,从而将主库的压力分解掉,主库就主要负责数据的增删改等,而从库主要负责查询。另外有了主、从库,也给生产数据增加了一层安全性,即备份。万一主库出了什么问题,从库却还在。       …

    2023年2月10日
    1.1K00
  • mysql内存占用过高的问题

    现象:在mysql运行一天之后,发现内存占用量达到总内存的百分之77,且swap被占用百分之50 问题检查如下: 第一步:开启内存使用的监控服务 第二步: 查看正常实例的使用情况 第三步: 查看内存监控表数据 问题解决:         当事件的内存占用是performance_schema过高的话,可以考虑关闭或者减少该事件使用内存的量,操作如下

    2023年7月26日
    31700

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注

在线咨询: QQ交谈

邮件:712342017@qq.com

工作时间:周一至周五,8:30-17:30,节假日休息

关注微信