redis主从库配置

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了redis主从库配置相关的知识,希望对你有一定的参考价值。

参考技术A 建立1个主库 2个从库

1、拷贝两个主库的配置文件(redis.windows.conf),自定义连个名字,写入如下配置,或者直接创建两个.conf文件,写入如下配置
2、使用redis-server xxxx.conf依次使用主从库配置文件启动redis即可

redis的主从复制和哨兵模式

Redis主从复制是什么?

行话:也就是我们所说的主从复制,主机数据更新后根据配置和策略,

自动同步到备机的master/slaver机制,Master以写为主,Slave以读为主

 

Redis主从复制能干些什么?

(1)读写分离

(2)容灾恢复

 

Redis配置主从复制(1主2从)

知识注意:

(1)配从(库)不配主(库)

(2)从库配置:slaveof 主库IP 主库端口

(3)info replication查看当前redis节点信息(是主还是从等等)

 

redis配置1主2从

开始配置:

这里做演示是装在一台机器上,方便学习(生产环境是装在不同机器上的)

我们这里并不安装三个redis,而是已copy三个配置文件来区分。

分别是:redis6379.conf,redis6380.conf,redis6381.conf

 技术图片

 

修改配置文件内容:(这里的修改都是为了区分不同机器,6379就是端口号

daemonize yes开启后台启动

pid /var/run/redis6379.pidpid文件以端口号来区分

P ort 6379指定端口

logfile "redis6379.log"指定log文件名字

dbfilename dump6379.rdb这里使用的是rdb持久化方式,那么就修改rdb快照文件名

(每个配置文件都需要修改)

 

修改好配置文件后,分别启动三个redis进程:

../bin/redis-server redis6379.conf

../bin/redis-server redis6380.conf

../bin/redis-server redis6381.conf

 

查看是否启动成功:

技术图片

可以看到redis三个进程分别在6380,6381,6379三个端口号启动了。

 

分别连接这三个redis进程,查看当前redis状态:

6379端口:

技术图片

 

6380端口:

 技术图片

 

6381端口:

技术图片

 

现在可以看到,三个redis进程状态都是master,都没有slave。

 

开始主从复制配置:

一个master,两个slave。

定义:6379当master,6380和6381都为slave

可以看到我们只是注意的地方:配从(库)不配主(库)

好的,分别在6380和6381上的redis去关联6379的redis:

slaveof 127.0.0.1 6379

技术图片

技术图片

(注意:我们这里是以命令方式去关联主的,当前redis关闭即失效。如果想要重新启动还能关联主,那么需要再配置文件中配置。)

 

然后我们再查看6380和6381端口redis的状态:

技术图片

技术图片

可以看到两台主机都已经改成slave了,而且还标识出master的信息。

如果已经出现以上图片显示,那么代表1主2从配置成功了。

 

测试redis的1主2从

 

(1)slave1、slave2是从头开始复制还是从切入点开始复制?当前主机器上已经有了k1 k2 k3了,从机器才关联过来,那么在从机器上能拿到k1 k2 k3吗?

测试:

主服务器先写key

技术图片

 

从服务再去关联主服务器,去拿key

答案是可以的!!!分析一下,应该是从机器关联主机器时,会将主机器所有key都copy一份给从机器

 

(2)从机是否可以写?set可否?主服务器是否可以读呢?get可否

测试:

在从机上写:redis会提示你只是一个从机,是只能读不能写。

技术图片

 

在主机上读:可以读,主机可读可写

技术图片

 

 

(3)主机shutdown后情况如何?从机是上位还是原地待命

测试:

主机shutdown:

技术图片

查看从机状态:

技术图片

可以看到,从机状态还是没有改变,从机是在原地待命

 

(4)主机又回来了后,主机新增记录,从机还能否顺利复制?

测试:

从新启动主机,写入一个k5

技术图片

在从机上获取k5:

技术图片

从机上获取k5成功。

得出结论:

主机回来后并且新增记录,从机能顺利复制主机上的数据。

 

 

5其中一台从机down后情况如何?依照原有它能跟上大部队吗?

测试:

关闭从机,重新启动从机。

主机写入k6,从机上获取k6,会发现是不行的。

为什么呢?安装的时候已经说了:

(注意:我们这里是以命令方式去关联主的,当前redis关闭即失效。如果想要重新启动还能关联主,那么需要再配置文件中配置。)

如果不相信可以去看下当前从机的状态,它已经变成master了。

这里就不贴截图了。

 

薪火相传

什么是薪火相传?

上一个slave可以是下一个slave的master,slave同样可以接收其他

slaves的连接和同步请求,那么该slave作为了链条中下一个的master,

可以有效减轻master的写压力

 

注意:

中途变更转向:会清除之前的数据,重新建立拷贝最新的

 

设置薪火相传

slaveof 新主库IP 新主库端口

 

我这里还是拿之前配好的6379,6380,6381来做案例。

主机:6379

从机:6380,6381

 

将6381指向6380,。6380还是指向6379(不变)。

6381端口redis信息:

 技术图片

6380端口redis信息:

技术图片

可以看到6380端口的redis还是slave,但是它底下有一个slave,正是6381,好的现在我们已经配置成功了。

 

测试一下:在6379下修改个值,6380上一定是可以取到的,看看6381上能不能取到

 技术图片

技术图片

技术图片

ok,6381上也是可以拿到值的,那么薪火相传成功!!!!

 

反客为主

什么是反客为主?

当主机中宕机了,那么我们可以手动的停止从机与主机的同步,将从机转成主机。再将其他的从机与当前这台主机同步数据,另成一个体系。

 

命令介绍:

slaveof no one使当前数据库停止与其他数据库的同步,转成主数据库

 

反客为主案例:

假如现在主机挂掉了:这里是人为手动关闭,模拟挂掉

技术图片

查看从机状态:

 技术图片

这里可以发现master的状态是down,那么现在将80端口redis设置为主机,81端口redis做80端口的从机:

技术图片

slaveof no one使当前数据库停止与其他数据库的同步,转成主数据库

Info replication查看当前redis的一个信息,可以发现当前已经是master了

 

再将81关联到80上,再查看当前81上的信息,就可以看到关联的master是80的redis了。

slaveof 127.0.0.1 6380

技术图片

测试主从复制是否成功:

 技术图片

技术图片

测试成功!!在80上写数据,在81上可以读取到。

 

Redis主从复制原理

全量复制:

slave启动成功连接到master后会发送一个sync命令

master接到命令启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令,

在后台进程执行完毕之后,master将传送整个数据文件到slave,以完成一次完全同步

而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中。

 

增量复制:

master继续将新的所有收集到的修改命令依次传给slave完成同步

 

注意:

但是只要是重新连接master,回自动执行一次完全同步(全量复制)

 

哨兵模式(sentinel)

什么是哨兵模式?

反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库

 

实现哨兵模式

我们还是使用6379,6380,6381机器来演示。

(先调回1主2从情况,这里就不演示了。)

主机:6379

从机:6380,6381

(1)在/usr/local/redis/conf下创建一个名为sentinel.conf的文件,并写入内容

sentinel monitor 被监控数据库名字(自己起一个名字) 127.0.0.1 6379 1

上面最后一个数字1,表示主机挂掉后salve投票看让谁接替成为主机,得票数多redis成为主机

注意:这里要监控的是主机

技术图片

 

(2)启动哨兵

这是我的目录:

bin下面就是redis的一些启动脚本。

config下是我copy出来的redis配置文件和刚刚创建的sentinel.conf

技术图片

到config目录下执行命令启动哨兵:

../bin/redis-sentinel sentinel.conf

注意:这里的命令根据不同的redis安装目录也是会不相同的。

技术图片

好的,如果看到以上打印出得图就是启动成功。可以看到已经在监控6379了,而且还找到了6379的从机器6380和6381。

 

 哨兵测试

(1)原有的master挂了,会怎么样?

好的,我们测试一下,我们手动让6379挂掉,看下哨兵会怎么处理。

 

模拟6379宕机:(手动让6379宕掉)

技术图片

 

稍等一会,看到哨兵日志:

技术图片

这里已经检测到6379主机宕机,那么就会投票选出一个主机,这里可以看到的是选出的主机是6380。

 

我们去看下6380和6381的信息

6380:

技术图片

 

6381:

技术图片

以上截图已经可以看到,6380已经成了主机,而且6381已经改变了关联的主机,改成选举出来的6380了。

总结出:如果主机挂掉了,那么会在从机上投票选举出主机,并且修改剩余的从机关联到新的主机中。

 

2如果之前的master重启回来,会不会双master冲突?

测试开始:

重新启动6379端口的redis,查看它的信息,看一看是什么情况:

 技术图片

可以看到6379变成了slave,主机是6380。

 

而且启动6379时,哨兵打印出了一条日志:

 技术图片

意思:将从机6379关联到6380上。

 

总结:之前的master重新启动后,并不会冲突,会以从机的身份来关联主机。

注意:一组sentinel能同时监控多个Master

复制的缺点

复制的延迟:

由于所有的写操作都是先在master上操作,然后同步更新到slave上,所以从master同步到slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,slave机器数量的增加也会使这个问题更加严重。

 

 好的。到了这里主从复制和哨兵模式完成!!!

以上是关于redis主从库配置的主要内容,如果未能解决你的问题,请参考以下文章

Redis启用主从模式做读写分离

redis的主从复制master/slaver

配置redis主从复制

Redis 主从配置

Redis主从复制的配置过程

redis配置和主从复制