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