也就是咱们所说的主从复制,主机数据更新后根据配置和策略,自动同步到备机的master/slaver机制,Master以写为主,Slave以读为主。redis
读写分离 容灾恢复数据库
配从(库)不配主(库),一般状况下,能够准备几台机器,这里我准备了三台机器以下:spa
192.168.195.133 6379日志
192.168.195.133 6379code
192.168.195.133 6379blog
Init: 进程
一个Master两个Slave:内存
如何判断集群是否搭建成功:同步
(1)看主机日志it
(2)看备机日志
(3)info replication命令查看
常见问题解答:
1 切入点问题?slave一、slave2是从头开始复制仍是从切入点开始复制?好比从k4进来,那以前的123是否也能够复制
答: slave1 slave2 第一次接入将从头开始复制数据(全量复制) 之后则是增量复制。
2 从机是否能够写?set能否?
答:从机只能读
3 主机shutdown后状况如何?从机是上位仍是原地待命
答:当主机离开后,从机只能原地待命。
4 主机又回来了后,主机新增记录,从机还可否顺利复制?
答:当从机回来后,则将进行全量复制
5 其中一台从机down后状况如何?依照原有它能跟上大部队吗?
答:当从机down以后必须进行从新链接主机,而后才能进行数据的复制,若是从机在配置文件中设置为slaveof主机,则从机恢复以后能够直接链接主机,不须要从新链接(详见redis.conf文件中的REPLICAYION部分)
上一个Slave能够是下一个slave的Master,Slave一样能够接收其余slaves的链接和同步请求,那么该slave做为了链条中下一个的master,能够有效减轻master的写压力
中途变动转向:会清除以前的数据,从新创建拷贝最新的,Slaveof 新主库IP 新主库端口
是什么?
反客为主的自动版,可以后台监控主机是否故障,若是故障了根据投票数自动将从库转换为主库
怎么玩?
(1)调整结构 ,调整为一主二从的模式。 133 带着 134 和139.
(2)在根目录下的/myredis文件下 ,生成 sentinel.conf文件 名称绝对不能错。
(3)配置哨兵填写内容
在Sentinel的文件中:
sentinel monitor 被监控数据库名字(本身起名字) 192.168.195.133 6379 1
上面最后一个数字1,表示主机挂掉后salve投票看让谁接替成为主机,得票数多少后成为主机
(4)启动哨兵
命令: redis-sentinel /myredis/sentinel.conf
启动效果:
(5)现假设Master挂掉,让剩余的机器竞选成为主机
经过日志可见 此时 192.168.195.139成功竞选成为主机,而后从新主从之间继续工做。
问题:若是如今原来的主机重启以后,那么他的状态是主机仍是从机?
答:经过实践证实 ,原来的主机恢复以后,变为slave,继续协调工做。
补充:一组sentinel能同时监控多个Master
复制延时:因为全部的写操做都是先在Master上操做,而后同步更新到Slave上,因此从Master同步到Slave机器有必定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave机器数量的增长也会使这个问题更加严重。