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机器数量的增加也会使这个问题更加严重。

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

原文地址:https://www.cnblogs.com/lice-blog/p/11616362.html

时间: 2024-10-30 21:25:35

redis的主从复制和哨兵模式的相关文章

redis学习三,Redis主从复制和哨兵模式

Redis主从复制 java架构师项目实战,高并发集群分布式,大数据高可用,视频教程 1.Master可以拥有多个slave 2.多个slave可以连接同一个Master外,还可以连接到其他的slave 3.主从复制不会阻塞Master在主从复制时,Master可以处理client请求. 4.提供系统的伸缩性. 主从复制的过程 1.slave与Master建立连接,发送sync同步命令. 也就是说当用户在Master写入一条命令后,他们之间会通过一些算法把数据同步到每一个slave上. 2.Ms

Redis主从复制、哨兵模式

1.部署主从 环境:主IP:10.0.0.15,端口6379;从IP:10.0.0.16,端口6379. 原理:基于RDB持久化的功能来实现主从复制的功能. a.linux-redis1(10.0.0.15) cd /usr/local/redis/ grep "^[a-Z]" redis.conf # 列出几个修改过的配置 bind 10.0.0.15 protected-mode no port 6379 daemonize yes loglevel notice logfile

学习记录02 --- redis数据库的安装,以及主从复制和哨兵模式开启

emmmmmm,这个其实是28号老师布置下来的任务,但博客今天才开,思来想去还是把昨天的给补上吧,按住顺序来吧! 1.redis的安装 redis数据库的安装并不难,首先安装好依赖,因为redis是C语言编写,需要安装gcc来编译 yum install gcc-c++ -y(安装gcc) 执行上面的命令就安装完了gcc,接下来我们需要一个目录,用来安装redis 我是安装在/usr/local/redis里面的,所以直接执行下面的代码就可以创建一个目录 mkdir /usr/local/red

Redis篇6-replication主从复制与哨兵模式

概述 官方说明:https://redis.io/topics/replication 作用:读(Slave)写(Master)分离,容灾恢复 哨兵模式可以实现无人值守 缺点:主从复制无疑会带来延迟(Master机器同步到Slave机器),使用哨兵模式则延迟会更明显. 测试配置准备(一台主机两台备机) 拷贝多个配置文件分别命名区分 redis{port}.conf Master 端口6379 Slave1 端口6380 Slave2 端口6381 其他方便区别配置 使用后台方式启动服务 daem

Redis主从配置以及哨兵模式

Redis主从模式,应用写master,读slave,减轻master的压力. 配置主结点: daemonize yes port 6379bind 0.0.0.0 pidfile /opt/redis/redis_6379.pid 配置从结点的时候,除了port不同,还在末尾加上一行: slaveof 127.0.0.1 6379 启动服务 >redis-server /path/to/6379.conf >redis-server /path/to/6380.conf >redis-

redis的主从复制,哨兵值守

环境: 主服务器:192.168.10.10    Centos 7  redis-5.0.4 从服务器:192.168.10.129  Centos 7  redis-5.0.4 从服务器:192.168.10.130  Centos 7  redis-5.0.4 关于如何安装redis不再本文讨论范围内,不过您可以参考https://www.cnblogs.com/caesar-id/p/10846541.html 1.自定义192.168.10.10主服务器配置文件 [[email pro

Redis 高可用之哨兵模式

参考   : https://mp.weixin.qq.com/s/Z-PyNgiqYrm0ZYg0r6MVeQ 一.redis高可用解决方案 redis主从 优点:1.高可靠性,主从实时备份,有效解决单节点数据丢失问题. 2.可做读写分离,从库分担读操作,缓解主库压力 缺点:主库异常,需要手动主从切换    2.redis哨兵模式 优点:1.有效解决主从模式主库异常手动主从切换的问题 缺点:1.运维复杂,哨兵选举期间,不能对外提供服务 其他解决方案优缺点,可以查看 高可用 ,本篇主要介绍哨兵解

redis 4.0.13 -- 哨兵模式

1.前提 本文使用的是redis-4.0.13.tar.gz版本. redis各版本下载地址:http://download.redis.io/releases/ , 下载与安装单个redis查看我的另一篇<redis 4.0.13 -- 单个redis下载.安装.启动.验证>的“1.下载与初始化redis” 按照我之前的文章<redis 4.0.13 -- 主从模式>先在安装好主从. 但是主从模式有个缺点,如果主挂了,从没办法知道,所以需要哨兵.但是如果这个哨兵也挂了呢?所以需要

Redis主从复制之哨兵模式(sentinel)

介绍:反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库 调整结构:6379带着80.81 自定义的/myredis目录下新建sentinel.conf文件,名字绝不能错 配置哨兵,填写内容,sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1 ,上面最后一个数字1,表示主机挂掉后salve投票看让谁接替成为主机,得票数多少后成为主机 启动哨兵 正常主从演示 主机master挂了 投票选取 选81为主机  问题:如果