Redis哨兵(sentinel)

文章目录

简介
搭建框架
具体步骤
- 主要文件参数
- 开始配置
案例分析
- 原有的master挂了
哨兵运行流程和选举原理
- 主观下线
- [客观下线(Objectively Down)](#客观下线(Objectively Down))
- 选举出领导者哨兵(哨兵中选出兵王)
选新的master
使用建议

简介

将某一个从库转换为新主库，继续对外服务将某一个从库转换为新主库，继续对外服务

官网理论:https://redis.io/docs/manual/sentinel/

搭建框架

具体步骤

主要文件参数

sentinel.conf文件是哨兵的主要文件

先介绍一下具体的参数

bash 复制代码

bin:服务监听地址，用于客户端连接，默认本机地址
daemonize:是否以后台daemon方式运行
protected-mode:安全保护模式
port:端口
logfile:日志文件路径
pidfile:pid文件路径
dir:工作目录
sentinel monitor <master-name> <ip> <redis-port> <quorum> :设置要监控的master服务器,quorum表示最少有几个哨兵认可客观下线，同意故障迁移的法定票数。
sentinel auth-pass <master-name> <password>:master设置了密码，连接master服务的密码

sentinel down-after-milliseconds <master-name> <milliseconds>：
指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线

sentinel parallel-syncs <master-name> <nums>：

表示允许并行同步的slave个数，当Master挂了后，哨兵会选出新的Master，此时，剩余的slave会向新的master发起同步数据

sentinel failover-timeout <master-name> <milliseconds>：

故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败

sentinel notification-script <master-name> <script-path> ：

配置当某一事件发生时所需要执行的脚本


sentinel client-reconfig-script <master-name> <script-path>：

客户端重新配置主节点参数脚本

开始配置

可以在redis根路径下配置一个sentinel文件装接下来的配置文件

我们的3个哨兵都同时配置进192.168.111.169同一台机器

注意:myredis文件要在根目录存在

运行接下来的命令:

bash 复制代码

cd ~
mkdir myredis

vim 建立3个文件:

sentinel26379.conf

bash 复制代码

bind 0.0.0.0
daemonize yes
protected-mode no
port 26379
logfile "/myredis/sentinel26379.log"
pidfile /var/run/redis-sentinel26379.pid
dir /myredis
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111

sentinel26380.conf

bash 复制代码

bind 0.0.0.0
daemonize yes
protected-mode no
port 26380
logfile "/myredis/sentinel26380.log"
pidfile /var/run/redis-sentinel26380.pid
dir "/myredis"
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111

sentinel26381.conf

bash 复制代码

bind 0.0.0.0
daemonize yes
protected-mode no
port 26381
logfile "/myredis/sentinel26381.log"
pidfile /var/run/redis-sentinel26381.pid
dir "/myredis"
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111

首先要满足主从设置(要正常启动)

169机器上新建redis6379.conf配置文件，由于要配合本次案例，请设置masterauth项访问密码为111111，不然后续可能报错master_link_status:down

172机器上新建redis6380.conf配置文件，设置好replicaof

173机器上新建redis6381.conf配置文件，设置好replicaof

启动sentinel

bash 复制代码

redis-sentinel sentinel26379.conf --sentinel
redis-sentinel sentinel26380.conf --sentinel
redis-sentinel sentinel26381.conf --sentinel

案例分析

原有的master挂了

我们自己手动关闭6379服务器，模拟master挂了

问题思考:

1.两台从机数据是否OK ok

2.是否会从剩下的2台机器上选出新的master 会的

bash 复制代码

并且自己回修改相关的配置文件 填写
执行slaveof no one命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点成为其从节点 等等命令

3.之前down机的master机器重启回来，谁将会是新老大？会不会双master冲突？不会冲突 ,它会变成从机

哨兵运行流程和选举原理

当一个主从配置中的master失效之后，sentinel可以选举出一个新的master用于自动接替原master的工作，主从配置中的其他redis服务器自动指向新的master同步数据。一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换

bash 复制代码

1.判断是否下线
2.多个哨兵判断master是否下线
3.选出兵王
4.兵王去处理master问题,选择slave当master

主观下线

所谓主观下线（Subjectively Down，简称 SDOWN）指的是单个Sentinel实例对服务器做出的下线判断，即单个sentinel认为某个服务下线（有可能是接收不到订阅，之间的网络不通等等原因）。主观下线就是说如果服务器在[sentinel down-after-milliseconds]给定的毫秒数之内没有回应PING命令或者返回一个错误消息，那么这个Sentinel会主观的(单方面的)认为这个master不可以用了.

客观下线(Objectively Down)

ODOWN需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上已经宕掉

选举出领导者哨兵(哨兵中选出兵王)

当主节点被判断客观下线以后，各个哨兵节点会进行协商，先选举出一个领导者哨兵节点（兵王）并由该领导者节点，也即被选举出的兵王进行failover（故障迁移）

哨兵领导者，兵王如何选出来的？

Raft算法:

选新的master

选出新master的规则，剩余slave节点健康前提下:

bash 复制代码

1.redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点(数字越小优先级越高 )
2.复制偏移位置offset最大的从节点
3.最小Run ID的从节点

使用建议

哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用
哨兵节点的数量应该是奇数
各个哨兵节点的配置应一致
如果哨兵节点部署在Docker等容器里面，尤其要注意端口的正确映射
哨兵集群+主从复制，并不能保证数据零丢失