redis12(主服务宕机与sentinel监控配置)

手动处理主服务宕机：

        这里我们开启三个服务，其中6379端口的redis是主服务！

        主服务6379下有6380,6381两个slave

        再切到6380看一下 info replication  （这里注意 master_link_status 是up状态）

        我们偷偷的把6379给shutdown nosave  ，再次查看6380的信息，发现主服务的连接状态变为down

        这时候主服务已经宕机，slave1（6380）应该变为master继续支持服务，并关闭只读

        从服务6381将指向新的master 6380

Sentinel监控配置：

        目前我们讲的 Redis 还只是主从方案，最终一致性原则。那么假如果主节点凌晨突发宕机怎么办？运维从床上爬起来，然后手工进行从主切换，再通知所有的程序把地址统统改一遍重新上线？毫无疑问，这样的人工运维效率太低。

        所以我们必须有一个高可用方案来抵抗节点故障，当故障发生时可以自动进行从主切换，程序可以不用重启，运维可以继续睡大觉，仿佛什么事也没发生一样。Redis官方提供了这样一种方案 —— Redis Sentinel(哨兵)

sentinel的常用配置选项： 

        sentinel monitor def_master 127.0.0.1 6379 2   

        监控127.0.0.1 6379端口，连续2次连接不上（参数设置为2实验失败，改为1，我TM也不知道为什么）

        sentinel auth-pass def_master 123456

        设置一个密码

        sentinel down-after-milliseconds def_master 30000 

        这个配置项指定了需要多少失效时间，一个master才会被这个sentinel主观地认为是不可用的。 单位是毫秒，默认为30秒

        sentinel can-failover def_master yes 

        当前sentinel实例是否允许实施“failover”(故障转移) no表示当前sentinel为“观察者”(只参与"投票".不参与实施failover)， 

        sentinel parallel-syncs mymaster 1

        最多只有一台slave指向新的master（如果多台slave同时指向新的master IO压力过大）

用sentinel模式启动redis服务

        我们shutdown掉6379服务，这是哨兵模式将会提示，6380已经自动成为master

        果然6380已经自动成为master（）

        多台slave，哪个会继任为新的master？

        slave- priority：100    配置文件选项（优先级数字越小优先级越高，越容易被指定为master）