概念:主机数据更新后根据配置和策略, 自动同步到备机的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的奴隶。
