文章目录
- 简介
- 搭建框架
- 具体步骤
- 主要文件参数
- 开始配置
- 案例分析
- 原有的master挂了
- 哨兵运行流程和选举原理
- 主观下线
- 客观下线(Objectively Down)
- 选举出领导者哨兵(哨兵中选出兵王)
- 选新的master
- 使用建议
简介
将某一个从库转换为新主库，继续对外服务将某一个从库转换为新主库，继续对外服务
官网理论:https://redis.io/docs/manual/sentinel/
搭建框架
具体步骤
主要文件参数
sentinel.conf文件 是哨兵的主要文件
先介绍一下具体的参数
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文件要在根目录存在
运行接下来的命令:
cd ~
mkdir myredis
vim 建立3个文件:
sentinel26379.conf
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
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
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
redis-sentinel sentinel26379.conf --sentinel
redis-sentinel sentinel26380.conf --sentinel
redis-sentinel sentinel26381.conf --sentinel
案例分析
原有的master挂了
我们自己手动关闭6379服务器，模拟master挂了
问题思考:
1.两台从机数据是否OK ok
2.是否会从剩下的2台机器上选出新的master 会的
并且自己回修改相关的配置文件 填写
执行slaveof no one命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点成为其从节点 等等命令
3.之前down机的master机器重启回来，谁将会是新老大？会不会双master冲突？ 不会冲突 ,它会变成从机
哨兵运行流程和选举原理
当一个主从配置中的master失效之后，sentinel可以选举出一个新的master用于自动接替原master的工作，主从配置中的其他redis服务器自动指向新的master同步数据。一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换
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节点健康前提下:
1.redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点(数字越小优先级越高 )
2.复制偏移位置offset最大的从节点
3.最小Run ID的从节点
使用建议
- 哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用
- 哨兵节点的数量应该是奇数
- 各个哨兵节点的配置应一致
- 如果哨兵节点部署在Docker等容器里面，尤其要注意端口的正确映射
- 哨兵集群+主从复制，并不能保证数据零丢失
