redis持久化到mysql的方案_redis两种持久化的方案

redis两种持久化的方案

介绍:

mysql挂掉了,咋办找数据恢复到redis里面去,redis 的数据从哪里来,从mysql.redis有一个持久化的方案和高可用是有关系的,因为redis的操作是居于内存来的,但是它同时又是一个数据库,数据不可能保存到内存中,这个时候就需要redis定时内存中的数据持久化到硬盘上去.

redis持久化两种方案-RDB持久化

持久化就是redis的fork会创建一个子进程来运行,这个子进程和redis是一样的,就是相当于复制了一个redis

RDB持久化是在一段时间内达到某修改次数,就会把数据快照Snapshot持久化到硬盘上,eg:配置一分钟内修改100次,达到这个条件时,就会进行持久化操作,

持久化的文件创建在哪里

RDB文件格式时dump.rdb,每次当我们开机的时候就会读取这个文件,在这个文件配置里面有一个dir ./这个配置,

dir ./ # 这个是在redis文件里面的路径

dir /myredis 我们一般都会这样配置换成绝对路径,比较合理

什么时候触发RDB的持久化机制

当我们关掉redis的时候,要开启aof,没开启就会数据流失 ,

配置

自动触发

即：在redis.conf文件里配置，截图上的save

如：save 1 100(一分钟内修改100次)

如何停止：在redis.conf文件里配置save ""，或者通过命令config set save "",一般不会使用RDB持久化,使用AOF,把下面的两行注释掉,这两个持久化会同时开启,使用AOF,

手动触发

执行save命令：save时只管保存，其它不管，全部阻塞

执行bgsave命令：Redis会在后台异步进行快照操作， 快照同时还可以响应客户端请求。可以通过lastsave 命令获取最后一次成功执行快照的时间

执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义,是为了更新持久化文件 ,内存和磁盘数据同步

为什么要fork子进程

​因为redis5.0单线程,redis6.0多线程

RDB优势与劣势

优势

适合大规模的数据恢复

对数据完整性和一致性要求不高

劣势

在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。可能是你修改了之后,自动触发60s才快照一次,意外宕机了,没持久化,在开机的时候就会丢失

Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性能需要考虑

redis持久化两种方案-AOF持久化

AOF是什么

Aof保存的是appendonly.aof文件，是将Redis所有的写命令(增删改)记录到这个日志文件中，读命令不记录。

只允许在文件末尾追加内容，不允许改写文件。

Redis启动的时候就会读取该文件，简而言之，就是将文件中的命令重新执行一遍，完成数据恢复到内存的工作。

如何配置

即：在redis.conf文件里配置，截图上的改成appendonly yes。

持久化策略

通过Appendfsync配置

Appendfsync Always

每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好

Appendfsync Everysec

出厂默认推荐，异步操作，每秒记录，如果一秒内宕机，有数据丢失

AOF启动/恢复/修复

同样我们需要将AOF文件加载到内存中之后才能使用，如果AOF文件被破坏了，我们该如何修复呢？

正常恢复到内存中

将有数据的aof文件复制一份保存到对应目录，目录路径可以通过config get dir命令获取，重新启动Redis就可以了

异常恢复文件到内存中

备份异常AOF文件，使用命令对文件进行修复：redis-check-aof --fix 文件名，然后重新启动Redis就可以了

Rewrite重写AOF文件

什么是Rewrite

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制。

当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof进行重写文件

Rewrite原理

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)。

遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件。

而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

重写机制

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍，且文件大于64M时触发

AOF优势/劣势

优势

每次修改同步：appendfsync always同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好

每秒同步：appendfsync everysec异步操作，每秒记录，如果一秒内宕机，仅一秒内的数据丢失

劣势

相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb

Aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同

触发AOF机制后,你在主进程写一条命令先放在缓冲区,然后再放进磁盘持久化