Redis主从复制

一、什么是主从复制

　　主从复制就是主机更新数据之后,根据配置和策略,自动同步到从机的机制,其中Master以写为主,从机以读为主.

 

二、主从复制的目的

　　1、读写分离、性能扩展.

　　2、容灾快速恢复.

 

三、主从复制原理

　　1、每次从机连通后都会给主机发送sync(同步)指令.

　　2、主机接收到指令之后,立即进行存盘操作,发送RDB文件给从机.

　　3、从机接收到RDB文件之后,进行全盘加载.

　　4、加载完成之后,以后主机每次进行写操作,都会立刻将相同的命令发送给从机,从机执行相同的命令进行数据备份.

 

 

四、案例演示

4.1、一主二从

　　1、主从复制配置

　　　　准备好配置文件redis-6379.conf、redis-6380.conf、redis-6381.conf

　　　　redis-6379.conf配置文件

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

// 沿用Redis原生出厂的配置文件的内容 include /usr/local/myredis/bin/redis.conf   =====下面这些配置会覆盖掉出厂默认的配置文件内容===== // 保护模式关闭 protected-mode no   // 端口6379 port 6379   // 允许后台启动 daemonize yes   // 生成的日志文件路径和名称 logfile /usr/local/myredis/bin/log/redis-6379.log   // 生成的RDB文件名称 dbfilename dump-6379.rdb   // 生成的RDB文件路径 dir /usr/local/myredis/bin/dump/

　　　　redis-6380.conf配置文件

?

1 2 3 4 5 6 7

include /usr/local/myredis/bin/redis.conf protected-mode no port 6380 daemonize yes logfile /usr/local/myredis/bin/log/redis-6380.log dbfilename dump-6380.rdb dir /usr/local/myredis/bin/dump/

　　　　redis-6381.conf配置文件

?

1 2 3 4 5 6 7

include /usr/local/myredis/bin/redis.conf protected-mode no port 6381 daemonize yes logfile /usr/local/myredis/bin/log/redis-6381.log dbfilename dump-6381.rdb dir /usr/local/myredis/bin/dump/

　　2、同时启动redis-6379.conf、redis-6379.conf、redis-6379.conf三台服务器.

　　3、使用命令slaveof <masterip> <masterport>  来建立主从关系,并且使用info replication来查看主从关系.

　　4、通过下图可以看到6379、6380、6381三台服务均已正常启动,并且6379作为主机,而6380、6381作为从机.

.

　　5、一主二从模式相关测试案例步骤

　　　　开启端口为6379的主机---->设置key1、key2----->6380、6381和6379建立主从关系---->6380和6381查询keys *,结果存在key1、key2---->手动down掉主机6379---->使用info replication查询6380、6381的状态,发现他们的主机依然是6379,只不过状态是down.

　　　　1、切入点问题,slave1、slave2是从头开始备份主机数据,还是从切入点开始复制数据?

　　　　　　开始6379并没有与6380和6381建立主从关系就设置了key1、key2,他们建立主从关系之后能查到key1、key2说明只要他们建立关系,就直接能全盘复制到主机的数据,和切入时机没有关系.

　　　　2、主机的读写权限、从机的读写权限?

　　　　　　从下图中可以看到如下信息:(error) READONLY You can't write against a read only replica.说明从机只能读不能写,主机可以写也可以读,但是主机一般只做与写有关的操作.

　　　　3、主机shutdown后情况如何,从机是尚未还是原地待命?

　　　　　　从下图中可以看出,主机6379shutdown之后,从机6380和6381的角色并没有转变,还是slave,并且主机都是6379,处于原地待命状态.

　

　　　　4、主机回来之后,主机新增记录,从机还能顺利复制吗?

　　　　　　主机回来之后,新增记录,从机会继续复制主机数据.

　　　　5、其中一台从机down掉之后,他依旧能跟上大部队吗?

　　　　　　从机6381shutdown之后,重新开启6381服务器,这个时候6381的角色变成了master,它不再作为6379的从了,如果想继续建立主从关系需要再次使用命令slaveof 127.0.0.1 6379这个时候从机6381又会继续全盘加载6379RDB中的全部数据.

 

4.2、薪火相传

　　一、中间的slave可以是下一个slave的maser,中间的slave同样可接受其它slave的连接和同步请求,如果master宕机那么中间的slave可以作为下一个的可用master.

　　二、薪火相传的优点

　　　　1、可以降低master写的压力

　　　　　　相比较一个master连接n个slave的模式下,每个master每写一次数据,就会复制n份数据到n个slave,但是薪火相传模式下master每写一次,只需要传递一次数据到与其直接相连的slave,再由该slave传递给其它的master,中间这个slave存在的意义不是让他成为master,它的角色依旧是slave,即不可以写,它存在只是为了分担master的压力.

　　　　2、去中心化降低风险

　　　　　　maser如果宕机的情况下,中间的slave可以成为新的master,然后给其它的从机备份数据,并不会因为master宕机了,其它所有的从机都处于等待的状态.

　　三、薪火相传的缺点

　　　　1、如果slave中途变更转向成为master,不会清除之前的数据,然后重新备份数据到它的从机

　　　　2、如果中间的slave宕机的话,那么master就不能备份数据到其它的slave上

 

　　　　　　

　　四、薪火相传模式相关测试案例步骤

　　　　1、启动6379服务器---->启动6380服务器,使用命令slaveof 127.0.0.1 6379---->启动6381服务器,使用命令slaveof 127.0.0.1 6380---->使用命令info replication来查看各个服务器之间的主从关系,如下图

　　　　6379的角色为master,它有一个从机是6380.

　　　　6380的角色为slave,但是有一点特殊,它既有一个master 6379同时也有一个salve6381,并且它也是只有读的功能,而没有写的功能.

　　　　6381的角色为salve,它是6380的一个slave.

　　2、如果中间的slave(6380)宕机的话,6381它还能接收同步数据吗?

　　　　中间的6380如果中途宕机了,那么6380后面的slave(6381)将不再同步master(6379)的任何数据,但是6381显示它的主机还是6380,如果这个时候6380重新连接回来之后,6380的角色变成了master,这个时候6380写入数据,它的数据会同步到6381上面,如果6380使用命令slaveof 127.0.0.1 6379,那么它们就重新恢复到了原来的薪火相传模式中.

　　　　　

五、哨兵模式

　　使用哨兵监控主机是否发生故障,如果主机发生了故障,根据哨兵投票数自动将票数高的从库转换为主库

 

　    　

 

　　1、一个主库6379、从库6380、从库6381,一个哨兵sentinel.conf

　　2、新建一个配置文件sentinel.conf,配置文件的名称是固定的

　　3、配置文件内容

?

1 2 3 4 5 6 7

// monitor6379:我们自定义的一个名称 // 127.0.0.1:哨兵监视的主机IP // 6379:端口 // 1:哨兵的投票数,哨兵的个数一般配置值为奇数个.例如,主机宕机了,这个时候哨兵开始投票,3个哨兵中有2个人投票给了你,那么你就是新的master // 我们这里只配置了一个哨兵,所以配置为1,如果有三个哨兵投票,那么这个地方应该配置为2   sentinel monitor monitor6379 127.0.0.1 6379 1

　　4、启动哨兵

?

1	./redis-sentinel sentinel.conf

　　5、开启6379、6380、6381三台服务器,其中6379为master,6380和6381为6379的slave.(6380 slaveof 6379 、6381 slaveof 6379)

　　6、手动shutdown 6379,然后过一会可以看到他们在投票推举新的master,最终的结果是6381成为新的master

 

　　7、主机下线之后,从该主机所有的从机中挑选出新的master所遵循的规则(其中判断顺序:第一点>第二点>第三点)

　　　　一、选择优先级靠前的

　　　　　　redis.conf中配置 slave-priority 100(数值越小,优先级越高).

　　　　二、选择偏移量最大的

　　　　　　谁从master中获取的数据最多,那么谁的偏移量就越大.

　　　　三、选择runid最小的从服务

　　　　　　每个从服务启动之后都会随机生成一个40位的runid.

　　8、挑选出新的主服务之后，sentinel 向原主服务的从服务发送 slaveof 新主服务 的命令，新的slave备份新master的数据

　　9、当已下线的服务重新上线时，sentinel会向其发送slaveof命令，让其成为新主的slave