一、什么是主从复制
主从复制就是主机更新数据之后,根据配置和策略,自动同步到从机的机制,其中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配置文件
// 沿用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配置文件
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配置文件
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、配置文件内容
// monitor6379:我们自定义的一个名称
// 127.0.0.1:哨兵监视的主机IP
// 6379:端口
// 1:哨兵的投票数,哨兵的个数一般配置值为奇数个.例如,主机宕机了,这个时候哨兵开始投票,3个哨兵中有2个人投票给了你,那么你就是新的master
// 我们这里只配置了一个哨兵,所以配置为1,如果有三个哨兵投票,那么这个地方应该配置为2
sentinel monitor monitor6379 127.0.0.1 6379 1
4、启动哨兵
./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