主从切换技术的方法是:当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用。这不是一种推荐的方式,更多时候,我们优先考虑哨兵模式。

一、哨兵模式概述

哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行。其原理是哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例。

redis 哨兵关闭 redis哨兵模式启动和关闭_服务器


这里的哨兵有两个作用

  • 通过发送命令,让Redis服务器返回监控其运行状态,包括主服务器和从服务器。
  • 当哨兵监测到master宕机,会自动将slave切换成master,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让它们切换主机。

然而一个哨兵进程对Redis服务器进行监控,可能会出现问题,为此,我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控,这样就形成了多哨兵模式。

用文字描述一下故障切换(failover)的过程。假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行failover过程,仅仅是哨兵1主观的认为主服务器不可用,这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用,并且数量达到一定值时,那么哨兵之间就会进行一次投票,投票的结果由一个哨兵发起,进行failover操作。切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从服务器实现切换主机,这个过程称为客观下线。这样对于客户端而言,一切都是透明的。

1、sentinel作用

  • 当用Redis做主从方案时,假如master宕机,Redis本身无法自动进行主备切换
  • 而Redis-sentinel本身也是一个独立运行的进程,它能监控多个master-slave集群,发现master宕机后能进行自动切换。

2、sentinel原理

  • sentinel负责持续监控主节点的健康,当主节挂掉时,自动选择一个最优的从节点切换成主节点
  • 从节点来连接集群时会首先连接sentinel,通过sentinel来查询主节点的地址
  • 当主节点发生故障时,sentinel会将最新的主节点地址告诉客户端,可以实现无需重启自动切换redis

3、Sentinel支持集群

  • 只使用单个sentinel进程来监控redis集群是不可靠的,当sentinel进程宕掉后sentinel本身也有单点问题
  • 如果有多个sentinel,redis的客户端可以随意地连接任意一个sentinel来获得关于redis集群中的信息。

4、Sentinel版本

  • Sentinel当前稳定版本称为Sentinel 2,Redis2.8和Redis3.0附带稳定的哨兵版本
  • 安装完redis-3.2.8后,redis-3.2.8/src/redis-sentinel启动程序 redis-3.2.8/sentinel.conf是配置文件。

5、运行sentinel两种方式(效果相同)

  • 方法1:redis-sentinel /path/to/sentinel.conf
  • 方法2:redis-server /path/to/sentinel.conf --sentinel
  • 以上两种方式,都必须指定一个sentinel的配置文件sentinel.conf,如果不指定,将无法启动sentinel。
  • sentinel默认监听26379端口,所以运行前必须确定该端口没有被别的进程占用。

6、sentinel.conf配置文件说明

  • 配置文件只需要配置master的信息就好啦,不用配置slave的信息,因为slave能够被自动检测到
  • 需要注意的是,配置文件在sentinel运行期间是会被动态修改的,例如当发生主备切换时候,配置文件中的master会被修改为另外一个slave。
  • 这样,之后sentinel如果重启时,就可以根据这个配置来恢复其之前所监控的redis集群的状态。

sentinel.conf配置文件注释

'''1、sentinel monitor mymaster 127.0.0.1 6379 2'''
#1)sentinel监控的master的名字叫做mymaster,地址为127.0.0.1:6379
#2)当集群中有2个sentinel认为master死了时,才能真正认为该master已经不可用了

'''2、sentinel down-after-milliseconds mymaster 60000'''
#1)sentinel会向master发送心跳PING来确认master是否存活,如果master在60000毫秒内不回应PONG 
#2)那么这个sentinel会单方面地认为这个master已经不可用了

'''3、sentinel failover-timeout mymaster 180000'''
#1)如果sentinel A推荐sentinel B去执行failover,B会等待一段时间后,自行再次去对同一个master执行failover,
#2)这个等待的时间是通过failover-timeout配置项去配置的。
#3)从这个规则可以看出,sentinel集群中的sentinel不会再同一时刻并发去failover同一个master,
#4)第一个进行failover的sentinel如果失败了,另外一个将会在一定时间内进行重新进行failover,以此类推。

'''4、sentinel parallel-syncs mymaster 1'''
#1)在发生failover主备切换时,这个选项指定了最多可以有多少个slave同时对新的master进行同步
#2)如果这个数字越大,就意味着越多的slave因为replication而不可用,这个数字越小,完成failover所需的时间就越长。
#3)可以通过将这个值设为 1 来保证每次只有一个slave处于不能处理命令请求的状态。

7、配置传播

  • 一旦一个sentinel成功地对一个master进行了failover,它将会把关于master的最新配置通过广播形式通知其它sentinel,其它的sentinel则更新对应master的配置。
  • 一个faiover要想被成功实行,sentinel必须能够向选为master的slave发送SLAVE OF NO ONE命令,然后能够通过INFO命令看到新master的配置信息。
  • 当将一个slave选举为master并发送SLAVE OF NO ONE`后,即使其它的slave还没针对新master重新配置自己,failover也被认为是成功了的。
  • 因为每一个配置都有一个版本号,所以以版本号最大的那个为标准:
  • 1)假设有一个名为mymaster的地址为192.168.1.50:6379。
  • 2)一开始,集群中所有的sentinel都知道这个地址,于是为mymaster的配置打上版本号1。
  • 3)一段时候后mymaster死了,有一个sentinel被授权用版本号2对其进行failover。
  • 4)如果failover成功了,假设地址改为了192.168.1.50:9000,此时配置的版本号为2
  • 5)进行failover的sentinel会将新配置广播给其他的sentinel,发现新配置的版本号为2时,版本号变大了,

说明配置更新了,于是就会采用最新的版本号为2的配置。