Redis哨兵模式

user2025

已于 2022-01-21 14:46:41 修改

阅读量1.5k

点赞数

分类专栏： Redis 文章标签： redis java 数据库

于 2020-07-30 21:19:15 首次发布

本文链接：https://blog.csdn.net/user2025/article/details/107501945

版权

Redis 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

文章目录

什么是哨兵模式

哨兵模式：用于对主从结构中每个redis实例进行监控，当出现故障时通过投票机制选择新的master，并将所有slave连接到新的master，并告知客户端新master地址

哨兵也是一个redis服务器，不提供读写服务，主要用来监控redis实例节点
哨兵为集群，通常设置为奇数个，一般至少3个哨兵，方便投票选举

哨兵模式的作用

（1）监控：哨兵监控master和slave是否正常运行
（2）通知：当监控的节点发送故障时，通知其他哨兵、客户端等，可以通过在配置文件配置脚本发送邮件、短信等方式实现
（3）自动故障转移：当master宕机时，哨兵通过投票机制选举一个slave作为新master，将其他slave连接到新master，并通知客户端新master地址

哨兵配置

Redis及其Sentinel配置项详细说明：https://blog.csdn.net/a1282379904/article/details/52335051
redis的安装：https://blog.csdn.net/user2025/article/details/105934987
redis的主从模式：https://blog.csdn.net/user2025/article/details/107466532

修改配置文件

环境： 因硬件资源不足，在同一台服务器配置一主两从，将配置文件/etc/redis.conf复制三份，分别放到etc的redis7001、redis7002、redis7003目录下，并按照下面的方式配置：

bind 172.16.0.9
protected-mode no   #保护模式
port 7001
pidfile "/var/run/redis7000.pid"      #进程文件名称,同一台服务器的多个redis使用不同的pid文件
logfile "/etc/redis7000/redis7000.log" #日志文件位置，,同一台服务器的多个redis应该使用不同的日志文件记录
dir "/etc/redis7001"   #redis数据存储位置,比如aof、rdb等文件存储位置
masterauth "123456nw"

将配置文件/etc/redis-sentinel.conf复制三份，分别放到etc目录的sentinel8001、sentinel8002、sentinel8003目录下，并按照下面的方式配置：
在主从模式基础上进行配置，通常情况下只需修改哨兵配置文件redis-sentinel.conf中的如下配置：

bind 172.16.0.9
protected-mode no
port 7002
dir "/etc/sentinel7002"
sentinel monitor mymaster 111.231.242.174 7001 2
sentinel auth-pass mymaster 123456nw
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 10000
logfile "/etc/sentinel7002/sentinel.log"

（1）指定哨兵监听的服务器网卡的ip地址

# 指定sentinel监听的服务器网卡的ip地址，切记云服务器上装redis时，这里绑定的内网ip地址，因为redis所在服务器的网卡是分配的内网ip，外网ip是内网的ip的映射
bind  云服务器内网ip地址

（2）哨兵默认是关闭保护模式的，开启该参数后，redis只会本地进行访问

# 开启
protected-mode yes 
# 关闭
protected-mode no

（3）配置哨兵的端口号

# 配置哨兵服务的服务端口，默认端口号为26379
port 26379

（4）设置当前哨兵进程的工作目录

dir /test/data

（5）配置认定master宕机需要的最少票数，一般设置为监视master的哨兵总数的一半+1 【可以修改需要的数量】
master的名称只能包含英文字母，数字，和【.-_】这三个字符，需要注意的是master-ip 要写真实的ip地址而不要用回环地址（127.0.0.1）

sentinel monitor 自定义的master名称 master的地址 master的端口号  需要的最少票数
举例：sentinel monitor mymaster 198.16.0.9 9000 2

配置文件只需要配置master的信息就可以了，不用配置slave的信息，因为slave的信息能够被自动检测到(master节点会有关于slave的消息)。需要注意的是，配置文件在sentinel运行期间是会被动态修改的，例如当发生主备切换时候，配置文件中的master会被修改为另外一个slave。这样，之后sentinel如果重启时，就可以根据这个配置来恢复其之前所监控的redis集群的状态。
（6）设置哨兵连接master和slave时需要的密码，注意：master和slave节点设置的密码必须相同【如果配置了密码，需要配置】

sentinel auth-pass mymaster 123456  #123456为master和slave节点的密码

（7）配置认定master多少毫秒没有响应，Sentinel就认为这个master不可用，Sentinel就会将这个master节点标记为主观下线

sentinel down-after-milliseconds master的名称 失联时间（单位默认为毫秒） 
举例：sentinel down-after-milliseconds mymaster 3000
注意：master的名称必须与认定master宕机需要的最少票数的配置中的master名称一致

只有一个 Sentinel进程将实例标记为主观下线并不一定会引起实例的自动故障迁移
只有在足够数量的Sentinel都将一个实例标记为主观下线之后，实例才会被标记为客观下线，这时自动故障迁移才会执行
表决票数：用来判断某个Redis 服务器是否下线的参数。Redis下线需要的最少票数，比如有10个哨兵在监控某个master节点，如果需要至少6个哨兵发现master主观下线后，才认为master客观下线，命令中就需要配置参数为6

（8）指定在执行故障转移时，最多可以有多少个slave节点可以同时同步master实例。设置的slave节点数越小，则同步的时间越长，完成故障转移所需的时间就越长【slave节点数越少，master节点开启的进程数越少，master节点的压力也就越小】

sentinel parallel-syncs 自定义的master名称（与1、2中的保存一致） slave节点数量
举例：sentinel parallel-syncs mymaster 1

（9）如果在指定时间（ms）内未能完成failover（故障转移）操作，则认为该故障转移失败

sentinel failover-timeout 自定义的master名称  时间
举例：sentinel failover-timeout mymaster 10000

(10) 哨兵模式日志文件位置配置，以及查看哨兵日志【哨兵启动后才会配置文件中生成】

配置日志文件的位置

logfile "/var/log/redis/sentinel.log"

查看哨兵日志

tailf /var/log/redis/sentinel.log

启动哨兵，并通过客户端连接哨兵

#启动哨兵
redis-sentinel /etc/redis-sentinel.conf  &
redis-sentinel 哨兵配置文件  后台运行符号&

#连接哨兵，使用和连接redis服务器一样的命令，端口号不一样
redis-cli -h www.onething.top -p 26379
注意：如果哨兵和redis客户端在同一台云服务器，ip地址不能配置回环地址，应配置云服务器内网ip

通过redis-cli连接上哨兵以后，不能执行一般的redis命令，但可以通过info Sentinel命令查看信息
在这里插入图片描述
注意：哨兵启动后，配置文件/etc/redis-sentinel.conf会发生变化，配置文件中会记录slave节点ip地址和端口号、其他哨兵的ip地址、端口号、哨兵的唯一识别码

测试主从切换

ps -ef|grep redis  #查询需要关闭的redis进程id
kill -9  进程id1

关闭master节点

关闭master节点，slave节点会变为master节点，这个过程中会删除配置文件中的原配置：salveof 原master的IP地址端口号，另一个从服务器也会更新配置文件中新master的IP地址：salveof 新master的IP地址端口号
在这里插入图片描述

重启master节点

一段时间后再重新启动master节点，原master节点自动由master状态变为salve状态，配置文件的末尾会自动添加一行配置：slaveof 新master的IP地址端口号

哨兵的自动故障转移原理

当master节点宕机，那么哨兵会通过选举机制，从salve中选出一个新Master，并将原Master服务器标记为客观下线，其他slave会连接到新master。已经宕机的master再重新启动，自动切换成slave，不会自动恢复成master。
在哨兵模式的监控过程中，哨兵的配置文件根据master、slave的状态动态修改，主从服务器的配置文件也会动态的添加或删除【salveof 新master的IP地址端口号】