您的位置:首页 > 数据库 > Redis

redis中持久化机制(九)

weixin_43113679 2019-05-14 17:05 19 查看
版权声明:如需转载,请写明出处 https://blog.csdn.net/weixin_43113679/article/details/90210541

redis虽然不是关系型数据库,但是它也应该有持久化,要不虽然它是直接在内存里进行操作,但是如果出现宕机,或者其他错误想把数据恢复不就废了吗?

https://www.geek-share.com/detail/2721052161.html
上面这个博客详细的写了redis实现持久化的两个AOF和RDB,我就不再多说一遍了,不过请详细的看,对你的益处会非常大的
但是因为我是用的windows下面的会有点不一样,所以持久化进程的实施我没看他的

持久化过程的实施(windows)

其实和windows和Linux系统之间redis没什么太大的区别(有的linux用命令操作在windows里不行,因为那时linux命令,),你下载的时候都看到redis有windows和linux两个版本,关于内部的肯定都一样的,要不这并不就成重大失误了吗,有区别的也就是操作redis配置文件的过程区别,配置文件的别名的区别,最终的目的和实现的结果是一样的

第一个不同的就是配置文件,我看到很多网上的redis.conf是配置持久化的文件,我是没找到(可能我下的是windows版本,他们下的是Linux版本),在windows里是redis.windows.conf配置文件里配置持久化
根据上面那个博客的前提下改改

0.编辑redis.windows.conf(在你安装的文件夹下)将redis的启动设置为后台启动(守护进程)(windows不支持)


看到黄色的了,,翻译过来就是windows系统不支持守护进程,所以就别想了
守护进程https://www.cnblogs.com/burningleaf/p/9736911.html

1.RDB(快照)持久化测试

在redis里,默认使用RDB模式。因为RDB模式重建数据库比较快。

(1)修改配置文件RDB持久化频率


黄色染料里的三行写的是RDB持久化里
指定在多长时间内,有多少次更新操作,就将数据同步到数据文件,可以多个条件配合

save         规定时间(秒)内             进行至少多少次更改就写入RDB
save           900 									1            	//900秒内至少进行一次更改写入RDB

(2)将rdb文件的生成目录改为/var/redis目录下(var目录用于存放系统经常变化的文件)


第一个基本上是现成的,第二个自己改,特别提醒/var前的那个 点 一定要有

(3)重启redis服务进行测试:

重启:(由于缺少/var/redis目录而报错)

redis-server  redis.windows.conf  //redis.windows.conf  需要在应用的当前文件夹下写命令

在用户写这条命令会出现

C:\Users\lenovo>redis-server redis.windows.conf
Invalid argument during startup: Failed to open the .conf file: redis.windows.conf CWD=C:\Users\lenovo

不成功,我就切到redis文件夹下,就成功了,但是还是报错这是另外一个错误

因为刚刚修改的redis.windows.conf光修改没有添加/var/redis目录所以有问题,这也说明了不是redis自己创建,而是必须手动创建var文件夹和redis文件夹,并把dump.rdb移动到 var/redis/ 下

D:\redis>redis-benchmark -n 2000    //redis性能检测工具执行2000次命令
D:\redis>redis-cli
127.0.0.1:6379> keys *    //测试客户端是否有key
1) "counter:__rand_int__"
2) "mylist"
3) "key:__rand_int__"

关闭服务器重启
直接把cmd.exe给关闭了,服务器也就关闭了
客户端查看是否有数据(服务器重启之后仍然有数据证明被持久化)

2.AOF持久化测试

首先清空数据库

127.0.0.1:6379> flushall
OK
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379>

在Redis的配置文件中存在三种同步方式,它们分别是:

appendfsync always #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec #每秒钟同步一次,该策略为AOF的缺省策略。
appendfsync no #从不同步。高效但是数据不会被持久化。

(1)开启AOF持久化

修改配置开启AOF

(2)修改同步方式(默认就是每秒记一次)

(3) 重写机制:(也就是将aof文件重新整理一下) 达到64M之后每增长百分之百重写一次

(4)测试AOF持久化操作

1.重启redis服务并查看/var/redis目录(aof文件的生成位置与上面RDB持久化的文件生成位置一个目录)
重启大家肯定会了
在启动时要这么启动,不要直接redis-server,因为此时aof文件还不存在(因为是第一次)

D:\redis>redis-server redis.windows.conf

看到上面的就应该知道怎么启动了吧,这样再去var/redis文件夹下去看,此时appendonly.aof文件生成了,虽然里面是空
2.客户端执行两次redis操作

3.打开appendonly.aof文件查看

解释: *2 *3 * 5分别代表这条命令占据的行数
*2: select 0 使用默认的redis数据库

*3: set a test

5 lpush lkey1 aaa bbb ccc
也就是redis会根据上面的aof文件重新执行脚本进行数据的恢复。
断开连接,关闭redis,再打开查看所有的key

在这遇到了个问题,在重新打开redis-server时没有跟着加上redis.windows.conf,
所以在keys *时根本没有旧的数据,相当于你打开redis-server中没有读取RDB或者AOF中历史的记录,所以是空的
(5)测试AOF文件的重写(对AOF文件进行压缩,对数据进行处理)

int
$1
1
*3
$6
incrby
$3
int
$1
1
*3
$6
incrby
$3
int
$1
1
*3
$6
incrby
$3
int
$1
1
*3
$6
incrby
$3
int
$1
1
*3
$6

查看appendonly.aof文件的大小

(6)客户端重写AOF文件:(整理AOF文件,只保留AOF的结果,多次increby 变为结果)


内容:(操作已经进行合并)

所以在AOF日志文件里会有很多经常对一个key的操作,会使aof文件越来越大,所以经常和bgrewriteaof用,可以缩小AOF的文件大小,把对一个key的操作合并成一条命令,每天用bgrewriteaof定期重新整理数据
注意:

如果需要将redis数据库从一台服务器复制到另一台服务器,可以将aof文件和rdb文件进行拷贝,复制到另一台机器的redis工作目录下面,默认优先加载aof文件。
    
Redis中AOF执行的细节
https://zhengdl126.iteye.com/blog/2191834
特别需要注意的是上面博客上的运维上的建议:为了保证高性能,数据没有做dump,也没有用aof。因为不做dump发生的故障远远低于做dump的时候,即使数据丢失了,自动修复脚本可以马上数据恢复。毕竟对海量数据redis只能做数据分片,那么落到每个节点上的数据量也不会很多,
用redis本来就是为了达到变态的性能,虚拟内存、aof看起来都有些鸡肋

标签: