概念:主机数据更新后根据配置和策略, 自动同步到备机的master/slaver
机制,Master以写为主,Slave以读为主。
作用:
slave
启动成功连接到master
后会发送一个sync
命令;slave
服务在接收到数据库文件数据后,将其存盘并加载到内存中;下面结合实战和理论解释。
缺点: 由于所有的写操作都是先在Master上操作,然后同步更新到Slave上,所以从Master同步到Slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave机器数量的增加也会使这个问题更加严重。。
配置原则:
slaveof 主库IP 主库端口
redis.conf
文件;(下面有个例子,从机down
了之后,再回来就没有了,需要重新SLAVEOF
连接。)info replication
查看当前库的信息(是从库还是主库。以及其他信息);redis.conf
文件,也就是每个库(在不同机器)有一个redis.conf
;daemonize yes
;dump.rdb
名字;实操配置:
①编写三个配置文件:
②修改配置
③修改LOG等
搭建三台客户端。一开始都是主库:
也就是: 一个Master两个Slave。
相关演示:
可以查看主机的日志,此时发现有两个slave
挂在主机下面:
以及备机的日志:
用info replicatino
查看:
相关问题:
(1)切入点问题?slave1、slave2是从头开始复制还是从切入点开始复制? 比如从k4进来,那之前的123是否也可以复制?
答: 可以。
(2 )从机是否可以写?set可否?
答: 不可以,主要是读。
(3 )主机shutdown后情况如何?从机是上位还是原地待命
答: 从机待命。还是slave
。
(4 )主机又回来了后,主机新增记录,从机还能否顺利复制?
答:可以,老领导回来了,我继续跟着你。
(5) 其中一台从机down后情况如何?依照原有它能跟上大部队吗?
答: 不可以。需要重新SLAVEOF
连接。上面也说过了
每次与master断开之后,都需要重新连接,除非你配置进redis.conf
文件;(从机down
了之后,再回来就没有了,需要重新SLAVEOF
连接。)
上一个Slave可以是下一个slave的Master,Slave同样可以接收其他 slaves的连接和同步请求,那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力。
如果中途变更转向:会清除之前的数据,重新建立拷贝最新的。
命令: slaveof 新主库IP 新主库端口
。
演示:
6379
作为Master
,6380
连接到6379
,然后6381
连接到6380
。(注意此时6380
也是slave
)
在一个Master
两个slave
的情况下,如果主机挂了,从库需要手动调用SLAVEOF no one
命令,来使当前数据库停止与其他数据库的同步,转成主数据库。
演示:
配置
/myredis
目录下新建sentinel.conf
文件,名字绝不能错。sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1
。sentinel monitor host6379 127.0.0.1 6379 1
。如果6379
挂了,谁的票数多余1票,就自动化成为主机;redis-sentinel /myredis/sentinel.conf
一组sentinel能同时监控多个Master。
演示:
①一开始,master
挂了。
②查看sentinel
文件内容变化。
③重新看,6780
已经自动成为了master
。
④如果之前的master
即6379
重启回来,会不会双master
冲突?答:不会,之前的master
变成现在的master
的奴隶。