Redis的哨兵机制
主从切换:当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这时需要人工的干预,很不方便,还可能造成一段时间内的服务不可用。所以在redis2.8开始正式提供了sentinel(哨兵)架构来解决这个问题。
哨兵是一个分布式系统,你可以在一个架构中运行多个sentinel进程,这些进程会接收关于主服务器是否下线的信息,并使用投票协议来决定执行自动故障迁移,以及选择那个slave作为新的master。
哨兵模式是一种特殊的模式,首先redis提供了哨兵命令,哨兵是一个独立的进程,作为进程,它会独立运行。
Redis 的 Sentinel 系统用于管理多个 Redis 服务器, 该系统执行以下三个任务:
- 监控:sentinel会不断的检查你的主从服务器是否运行正常
- 提醒:当被监控的某个redis服务器出现问题时,sentinel会通过api向管理员或者其他应用程序发送通知
- 自动故障迁移:当一个主服务器不能正常运行时,sentinel会开始一次自动故障迁移操作,它会将失效的主服务器的其中一个从服务器升级为新的主服务器,并让失效的主服务器的其他从服务器改为复制新的主服务器;当客户端试图连接失效的主服务器时,集群也会向客户端返回新的主服务器的地址,使集群可以使用新的主服务器替换失效的服务器。
单哨兵模式:
多哨兵模式:
主观下线和客观下线
- 主观下线:单个 哨兵对服务器做出的下线判断。注意, 一个服务器必须在 master-down-after-milliseconds 毫秒内, 一直返回无效回复才会被 Sentinel 标记为主观下线。
- 客观下线:多个哨兵在对同一个服务器做出 下线 判断, 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后, 得出的服务器下线判断。 (一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线。)
每个哨兵都在干什么?
- 每个sentinel以每分钟一次的频率向它所知的主服务器、从服务器以及其他sentinel发送一个ping命令
- 如果一个实例距离最后一次有效回复ping命令的时间超过down-after-milliseconds 选项所指定的值,那么这个实例会被标记为主观下线。
- 如果一个主服务器被标记为主观下线, 那么正在监视这个主服务器的所有 Sentinel 要以每秒一次的频率确认主服务器的确进入了主观下线状态。
- 如果一个主服务器被标记为主观下线, 并且有足够数量的 Sentinel (至少要达到配置文件指定的数量)在指定的时间范围内同意这一判断, 那么这个主服务器被标记为客观下线。
- 一般情况下, 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有主服务器和从服务器发送 INFO 命令。 当一个主服务器被 Sentinel 标记为客观下线时, Sentinel 向下线主服务器的所有从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
- 当没有足够数量的 Sentinel 同意主服务器已经下线, 主服务器的客观下线状态就会被移除。 当主服务器重新向 Sentinel 的 PING 命令返回有效回复时, 主服务器的主观下线状态就会被移除。
哨兵模式的优点:
- 哨兵集群基于主从复制模式,享有主从复制的所有优点
- 自动切换主从节点,故障转移,系统可用性高
哨兵模式的缺点:
- 哨兵模式配置复杂
- redis不好在线扩容,当集群容量达到上限,在线扩容就十分麻烦
哨兵配置:
配置sentinel.conf
#哨兵实例运行的端口
port 26379
#哨兵的工作目录
#dir /tmp
#哨兵的主节点IP PORT
#master-name 可以自己命名主节点名字,只能由A-Z , 0-9 , ".-_"组成
#quorum 配置多少个哨兵统一认为master主节点失联,那么客观上认为主节点失联了
#指示 Sentinel 去监视一个名为 mymaster 的主服务器, 这个主服务器的 IP 地址为192.168.1.113, 端口号为 6379 , 而将这个主服务器判断为失效至少需要 2个 Sentinel 同意
#sentinel monitor <master-name> <ip> <redis-port> <quoum>
sentinel master mymaster 192.168.1.113 6379 2
#当在redis实例中开启了requirepass foobared 授权密码,这样所有的redis实例的客户端都需要提供密码
#设置哨兵连接主从密码,注意必须设置为主从设置一样的验证密码
#sentinel auth-pass <master-name> <password>
#指定多少毫秒之后 主节点没有应答哨兵,此时哨兵主观上认为主节点下线 默认30s
#sentinel down-after-milliseconds <master-name> <milliseconds>
#sentinel down-after-milliseconds mymaster 60000
#在执行故障转移时, 最多可以有多少个从服务器同时对新的主服务器进行同步, 这个数字越小, 完成故障转移所需的时间就越长。
#sentinel parallel-syncs <master-name> <numsalve>
#sentinel parallel-syncs mymaster 5
#故障转移的超时时间:
#1.同一个sentinel对同一个master两次failover之间的间隔时间
#2.当一个slave从一个错误的master那里同步数据开始计时,直到salve被纠正向正确的master那里同步数据
#3.当想要取消一个正在进行的failover所需要的时间
#4.当进行failover时,配置所有salve指向新的master所需的最大的时间,不过,即使超时,slave依然会被纠正只想正确的master,但是不按照parallel-syncs配置的规格
#默认三分钟
#sentinel failover-timeout <master-name> <millseconds>
#sentinel failover-timeout mymaster 180000
#配置当某个事件发生时所需要执行的脚本,可以通过脚本来通知管理员,例如当系统运行不正常时发送邮件通知相关人员
#sentinel notification-script <master-name> <script-path>
#sentinel notification-script mymaster /xx/xx.sh
#客户端重新配置主节点参数脚本
#当一个master由于failover而发生改变时,这个脚本将会调用,通知相关的客户端关于master地址已经发生改变的信息
#sentinel client-reconfig-script <master-name> <script-path>
#sentinel client-reconfig-script mymaster /xx/xx.sh
启动:
./redis-sentinel sentinel.conf
95147:X 26 Aug 2020 15:20:33.037 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
95147:X 26 Aug 2020 15:20:33.040 # Sentinel ID is 95c21c6ee024f9f875f99d8dcfd344317c67da23
95147:X 26 Aug 2020 15:20:33.040 # +monitor master mymaster 192.168.1.113 6379 quorum 2
95147:X 26 Aug 2020 15:20:33.041 * +slave slave 192.168.1.113:6878 192.168.1.113 6878 @ mymaster 192.168.1.113 6379
95147:X 26 Aug 2020 15:20:33.044 * +slave slave 192.168.1.113:6377 192.168.1.113 6377 @ mymaster 192.168.1.113 6379