Redis哨兵模式

哨兵模式

哨兵的作用是监控Redis系统的运行状态

例子:一主二从 主机挂了 会自动从从机中选取出一个主机。

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6381,state=online,offset=84,lag=0
slave1:ip=127.0.0.1,port=6380,state=online,offset=84,lag=1

开启哨兵

1.配置哨兵sentinel.conf文件

  vim sentinel   #打开

配置这句话

sentinel  monitor  myredis   127.0.0.1 6379	1

最后的1 代表主机挂了 最少有多少个哨兵同意迁移的数量 会进行投票 选出主机

  redis-sentinel sentinel.conf 

如果Master节点断开了,这个时候就会从从机中随机选择一个服务器!(这里面有一个投票算法!)

如果主机回来了,只能归并到新主机下,当做从机,这就是哨兵模式的规则!

选取规则
在这里插入图片描述
优点:

1.哨兵集群,基于主从复制模式,所有的主从配置优点,它全有

2.主从可以切换,故障可以转移,系统的可用性会更好

3.哨兵模式就是主从模式的升级,手动到自动,更加健壮!

缺点:

1.redis不好在线扩容,集群容量一旦到达上限,在线扩容就十分麻烦!

2.实现哨兵模式的配置其实是很麻烦的,里面有很多选择!

完整配置

# Example sentinel.conf
 
# 哨兵sentinel实例运行的端口 默认26379
port 26379
 
# 哨兵sentinel的工作目录
dir /tmp
 
# 哨兵sentinel监控的redis主节点的 ip port 
# master-name  可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
  sentinel monitor mymaster 127.0.0.1 6379 2
 
# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
 
 
# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
 
# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步,
这个数字越小,完成failover所需的时间就越长,
但是如果这个数字越大,就意味着越 多的slave因为replication而不可用。
可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
 
 
 
# 故障转移的超时时间 failover-timeout 可以用在以下这些方面: 
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。  
#4.当进行failover时,配置所有slaves指向新的master所需的最大时间。不过,即使过了这个超时,slaves依然会被正确配置为指向master,但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
 
# SCRIPTS EXECUTION
 
#配置当某一事件发生时所需要执行的脚本,可以通过脚本来通知管理员,例如当系统运行不正常时发邮件通知相关人员。
#对于脚本的运行结果有以下规则:
#若脚本执行后返回1,那么该脚本稍后将会被再次执行,重复次数目前默认为10
#若脚本执行后返回2,或者比2更高的一个返回值,脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了,则同返回值为1时的行为相同。
#一个脚本的最大执行时间为60s,如果超过这个时间,脚本将会被一个SIGKILL信号终止,之后重新执行。
 
#通知型脚本:当sentinel有任何警告级别的事件发生时(比如说redis实例的主观失效和客观失效等等),将会去调用这个脚本,
这时这个脚本应该通过邮件,SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时,将传给脚本两个参数,
一个是事件的类型,
一个是事件的描述。
如果sentinel.conf配置文件中配置了这个脚本路径,那么必须保证这个脚本存在于这个路径,并且是可执行的,否则sentinel无法正常启动成功。
#通知脚本
# sentinel notification-script <master-name> <script-path>
  sentinel notification-script mymaster /var/redis/notify.sh
 
# 客户端重新配置主节点参数脚本
# 当一个master由于failover而发生改变时,这个脚本将会被调用,通知相关的客户端关于master地址已经发生改变的信息。
# 以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>总是“failover”,
# <role>是“leader”或者“observer”中的一个。 
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的
# 这个脚本应该是通用的,能被多次调用,不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
 sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

借鉴了老师的视频
尚硅谷
狂神

<think>我们正在讨论Redis哨兵模式的配置与实现。根据引用内容,用户提供了几个配置示例,但我们需要系统地解释哨兵模式的配置步骤和实现原理。步骤1:理解哨兵模式Redis哨兵(Sentinel)是一个分布式系统,用于管理多个Redis实例(主从结构),提供自动故障转移(failover)和高可用性。哨兵模式的核心功能包括:-监控:哨兵定期检查主节点和从节点的状态。-通知:当被监控的实例出现问题时,哨兵可以通过API通知系统管理员或其他程序。-自动故障转移:如果主节点故障,哨兵会启动故障转移过程:选择一个从节点晋升为主节点,并让其他从节点复制新的主节点。-配置提供者:客户端可以通过哨兵获取当前主节点的地址。步骤2:配置哨兵模式的基本步骤根据引用[2]和引用[3],配置哨兵模式通常包括以下步骤:1.准备Redis主从结构:首先需要配置一个主节点和至少一个从节点。例如:-主节点:运行在127.0.0.1:6380-从节点1:运行在127.0.0.1:6381-从节点2:运行在127.0.0.1:63822.创建哨兵配置文件:每个哨兵实例需要一个配置文件。通常,我们会创建多个哨兵实例(通常为奇数,如3个)以实现哨兵自身的容错。以配置三个哨兵为例(端口分别为26380,26381,26382):-复制模板配置文件:创建三个哨兵配置文件(如sentinel-26380.conf,sentinel-26381.conf,sentinel-26382.conf)。-修改每个配置文件,主要设置:port<哨兵端口>#每个哨兵使用不同端口daemonizeyes#以守护进程方式运行sentinelmonitor<master-group-name><master-ip><master-port><quorum>sentinelauth-pass<master-group-name><password>#如果主节点有密码例如:sentinelmonitormymaster127.0.0.163802sentinelauth-passmymaster123456注意:`<quorum>`(法定人数)是判定主节点故障至少需要的哨兵数量。这里设置为2,表示需要至少两个哨兵同意才能判定主节点故障。3.启动哨兵:redis-sentinel/path/to/sentinel-26380.confredis-sentinel/path/to/sentinel-26381.confredis-sentinel/path/to/sentinel-26382.conf4.验证:连接到一个哨兵实例,使用`infoSentinel`命令查看状态。步骤3:哨兵模式的工作原理-哨兵通过发送PING命令定期检查主从节点的健康状态。-如果主节点在配置的`down-after-milliseconds`时间内未回复,哨兵将其标记为“主观下线”。-当足够数量的哨兵(达到quorum)都将主节点标记为主观下线时,主节点被标记为“客观下线”。-然后,哨兵会选举一个领导者哨兵(使用Raft算法)来执行故障转移。-领导者哨兵选择一个从节点(通常选择数据最新的从节点)晋升为主节点,并让其他从节点复制新的主节点。-最后,哨兵更新配置:将旧主节点(如果重新上线)设置为新主节点的从节点。步骤4:注意事项-哨兵数量:通常至少需要3个哨兵以确保系统在部分故障时仍能正常工作(容忍一个哨兵故障)。-网络分区:哨兵系统需要大多数哨兵可达才能做出决策,因此奇数个哨兵(如3或5)可以避免脑裂。-客户端:客户端需要支持哨兵,能够通过查询哨兵获取当前主节点地址。步骤5:配置示例参考引用[2]中的配置片段,一个哨兵配置文件(如sentinel-26382.conf)可能如下:```plaintextport16382daemonizeyessentinelmonitormymaster127.0.0.163802sentinelauth-passmymaster123456```步骤6:启动和停止引用[3]展示了如何停止和启动所有节点(包括主从和哨兵)的示例命令。注意:生产环境中应避免直接使用kill命令,应使用服务管理工具。总结:Redis哨兵模式提供了高可用性,配置过程包括设置主从复制、配置多个哨兵实例以及启动哨兵。哨兵通过监控和自动故障转移确保Redis服务在节点故障时继续运行。§§相关问题§§1.Redis哨兵模式与集群模式有什么区别?2.如何配置哨兵的故障转移通知?3.哨兵模式在故障转移过程中如何处理客户端连接?4.如何监控哨兵系统的状态?</think>### Redis哨兵模式配置与实现 Redis哨兵(Sentinel)是一种高可用解决方案,用于监控主从架构中的Redis实例,实现自动故障检测和故障转移。以下是关键配置步骤和实现原理: #### **一、核心配置步骤** 1. **创建哨兵配置文件** 复制模板并修改端口和监听对象(每个哨兵独立配置): ```bash cp sentinel-26380.conf sentinel-26381.conf cp sentinel-26380.conf sentinel-26382.conf ``` 配置文件内容示例: ```plaintext port 16381 # 哨兵端口 daemonize yes # 后台运行 sentinel monitor mymaster 127.0.0.1 6380 2 # 监控主节点,2为法定同意数 sentinel auth-pass mymaster 123456 # 主节点密码 ``` [^2] 2. **启动哨兵进程** 分别启动三个哨兵节点: ```bash redis-sentinel sentinel-16380.conf redis-sentinel sentinel-16381.conf redis-sentinel sentinel-16382.conf ``` [^2] 3. **验证哨兵状态** 连接Redis执行命令查看哨兵信息: ```bash redis-cli -p 16381 info Sentinel # 输出主节点状态、从节点列表等 ``` 4. **故障转移流程** - 哨兵通过PING命令检测节点健康 - 主节点超时未响应 → 标记为**主观下线** - 多数哨兵确认 → 升级为**客观下线** - 选举领导者哨兵执行故障转移 - 选择数据最新的从节点晋升为新主节点 - 更新其他从节点复制目标 #### **二、关键参数解析** | 配置项 | 说明 | 示例 | |--------|------|------| | `sentinel monitor <name> <ip> <port> <quorum>` | 定义监控的主节点 | `sentinel monitor mymaster 127.0.0.1 6380 2` | | `sentinel down-after-milliseconds` | 判定节点失效的毫秒数 | 默认30,000ms | | `sentinel failover-timeout` | 故障转移超时时间 | 默认180,000ms | | `sentinel parallel-syncs` | 故障转移时同步新主的从节点数 | 默认1 | #### **三、实现原理** 1. **分布式监控** 多个哨兵节点组成集群,通过Gossip协议通信,避免单点故障。 2. **Raft共识算法** 故障转移时通过Raft选举领导者哨兵,需满足: $$ \text{同意票数} \geq \left\lfloor \frac{\text{哨兵总数}}{2} \right\rfloor + 1 $$ 3. **配置自动传播** 新主节点确认后,哨兵自动修改其他节点的`redis.conf`和`sentinel.conf`,更新主节点地址[^1]。 #### **四、注意事项** 1. **节点数量** 推荐部署**至少3个哨兵**(奇数个),法定人数(quorum)通常设为 $\frac{N}{2} + 1$(N为哨兵总数)。 2. **网络分区处理** 当网络分裂时,少数分区中的旧主节点会被置为只读模式,防止数据冲突。 3. **客户端集成** 客户端需支持哨兵协议,通过`SENTINEL get-master-addr-by-name`动态获取主节点地址。 > **故障转移演示**: > 当主节点(6380)宕机时,哨兵日志会显示: > ```plaintext > +sdown master mymaster 127.0.0.1 6380 # 检测到故障 > +vote-for-leader ... # 开始选举 > +failover-state-select-slave master mymaster # 选择新主 > +promote-slave slave 127.0.0.1:6381 ... # 提升从节点 > +switch-master mymaster 127.0.0.1 6380 127.0.0.1 6381 # 切换完成 > ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值