一、哨兵介绍
之前骚了一波复述的简介及应用场景,今天试了下他的哨兵模式;
哨兵是复述的高可用性(HA)解决方案,由一个或多个哨兵实例组成的哨兵系统可以监视任意多个主服务器,以及这些主服务器属下的所有从服务器,
并在被监视的主服务器进行下线状态时,自动将下线主服务器属下的某个从服务器升级为新的主服务器,然后由新的主服务器代替已下线的主服务器继续处理命令请求。
复述,提供的哨兵(哨兵)机制,通过哨兵模式启动复述后,自动监控主/从的运行状态,基本原理是:心跳机制+投票裁决
监控(监控):哨兵会不断地检查你的主服务器和从服务器是否运作正常。
提醒(通知):当被监控的某个复述,服务器出现问题时,哨兵可以通过API向管理员或者其他应用程序发送通知。
自动故障迁移(自动故障转移):当一个主服务器不能正常工作时,哨兵会开始一次自动故障迁移操作,它会将失效主服务器的其中一个从服务器升级为新的主服务器,
并让失效主服务器的其他从服务器改为复制新的主服务器;当客户端试图连接失效的主服务器时,集群也会向客户端返回新主服务器的地址,使得集群可以使用新主服务器代替失效服务器。
二,复述,哨兵搭建
测试采用2个哨兵,1个主复述,2个从复述。
复制5份redis.windows.conf文件并重命名如下(开发者可根据自己的开发习惯进行重命名):
master.6379。参看配置:
# 6379端口设置连接密码
requirepass grs
#连接密码
masterauth grs
slave.6380。参看配置:
端口6380
requirepass grs
masterauth grs
dbfilename dump6380。rdb
#配置主
slaveof 127.0.0.1 6379
slave.6381。参看配置:
端口6381
requirepass grs
masterauth grs
dbfilename dump6381。rdb
#配置主
slaveof 127.0.0.1 6379
sentinel.63791。参看配置(将原配置文件清空后添加如下内容)(另一个一样,只需要修改下端口):
63791
#主港的主人,2个哨兵选举成功后才有效,这里的master-1是名称,在整合的时候需要一致,这里可以随便更改
哨点监测master-1 127.0.0.1 6379 2
#判断主主的挂机时间(毫秒),超时未返回正确信息后标记为sdown状态
哨兵down-after-milliseconds master-1 5000
#若哨兵在该配置值内未能完成故障转移操作(即故障时主/从自动切换),则认为本次故障转移失败。
哨兵failover-timeout master-1 18000
#身份认证
哨兵auth-pass master-1 grs
#选项指定了在执行故障转移时,最多可以有多少个从服务器同时对新的主服务器进行同步,这个数字越小,完成故障转移所需的时间就越长
哨兵parallel-syncs master-1 1
这里有三个问题需要注意
第一,若通过redis-cli - h 127.0.0.1 - p 6379连接,无需改变配置文件,配置文件默认配置为绑定127.0.0.1(只允许127.0.0.1连接访问)
若通过redis-cli - h 192.168.180.78 - p 6379连接,需改变配置文件,配置信息为绑定127.0.0.1 192.168.180.78(只允许127.0.0.1和192.168.180.78访问)或者将绑定127.0.0.1注释掉(允许所有远程访问)
第二,masterauth为所要连接的硕士服务器的requirepass,如果一个复述,集群中有一个主服务器,两个奴隶服务器,当主服务器挂掉时,哨兵哨兵会随机选择一个奴隶服务器充当主服务器,鉴于这种机制,解决办法是将所有的主从服务器的requirepass和masterauth都设置为一样。
第三、哨点监测master-1 127.0.0.1 6379 2行尾最后的一个2代表什么意思呢?我们知道,网络是不可靠的,有时候一个哨兵会因为网络堵塞而误以为一个主复述,已经死掉了,当哨兵集群式,解决这个问题的方法就变得很简单,只需要多个哨兵互相沟通来确认某个主人是否真的死了,这个2代表,当集群中有2个哨兵认为大师死了时,才能真正认为该主已经不可用了。(前哨集群中各个哨兵也有互相通信,通过八卦协议)。
按如下循序依次启动服务
1, redis-server master.6379。参看
2, redis-server slave.6380。参看
3, redis-server slave.6381。参看
