redis哨兵一直选举master是挂掉的服务器

最新推荐文章于 2024-02-04 22:21:46 发布
原创 最新推荐文章于 2024-02-04 22:21:46 发布 · 505 阅读 · 2 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#redis #数据库 #缓存

在配置Redis哨兵系统进行主从故障转移时，发现哨兵无法正确选举新的主节点。问题源于只关闭了主服务的防火墙，而未关闭从机的防火墙，导致选举过程持续失败。解决方法是关闭从机的防火墙，从而顺利完成主机的切换，选择了6381作为新的主机。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

当我在学习redis的哨兵的时候，配置哨兵的时候发现了 问题

我使用的是一主二从三哨兵模式

当主服务挂掉时，由于我设置了哨兵监控，会将没有挂掉的从机里选举出一个作为主机；

之前配置文件的时候一直没有问题

直到我挂掉主服务时，从机依然不会发生变化，由于配置了日志，我便查看日志，发现哨兵在投票选举的时候还在选举挂掉的主机6379.。。。之后又会监控到该主机挂掉了，然后重新选，一直循环。。。。。

 之后发现，我只关闭了主机也就是6379的防火墙，没有关闭两个从机的防火墙导致一直选举失败；

从机执行命令关闭防火墙

systemctl stop firewalld.service 

 解决问题：重新选择6381作为主机

 

昭昭啊
关注
Redis主从复制+哨兵选举机制分析
qq_35267557的博客
09-15 936
Redis主从复制，主要是为了做读写分离，写数据从主库操作，读数据从从库读取。但是普通的主从如果主服务器挂了，从服务器不会自动切换为主服务器。Redis主从复制 +哨兵模式就是解决主服务器挂掉之后，哨兵监控到挂了之后，重新发起选举操作，让某台从服务器变为主服务器。从而继续提供服务。Redis集群模式，就是将数据分片存储到不同的服务器，真正的达到了分布式存储，不像主从复制一样，存在存储上限。但是集群之后每个节点如果挂掉，存储的数据就会丢失。
聊聊Redis哨兵选举与故障转移的实现
禅与计算机程序设计的艺术
07-16 1097
上一篇文章我们将哨兵主观下线的核心流程都分析完成，这一篇我们将接着之前的思路，将哨兵获取客观下线结果并结合raft协议完成哨兵leader选举完成故障转移的流程分析完成，希望对你有帮助。因为近期收到很多读者的私信，所以也专门创建了一个交流群，感兴趣的读者可以通过上方的公众号获取笔者的联系方式完成好友添加，点击备注。因为近期收到很多读者的私信，所以也专门创建了一个交流群，感兴趣的读者可以通过上方的公众号获取笔者的联系方式完成好友添加，点击备注。下线的看法，如果累加到的哨兵对于下线的看法大于或者等于我们配置。
ERROR——redis哨兵模式主机挂掉，不能自动选举新的master
weixin_48185643的博客
12-27 2936
这里写目录标题实验环境报错现象解决方法 实验环境 20.0.0.10 (master) 20.0.0.11 (slave) 20.0.0.12 (slave) 报错现象 当我把master shutdown后 sentinel 不能自动选举出新的master并，出现 failover-abort-no-good-slave 错误 解决方法 修改redis.conf 三台全部修改为 bind 0.0.0.0 问题解决！ ...
redis集群选举机制
热门推荐
祈雨v的博客
02-02 2万+
概要 当redis集群的主节点故障时，Sentinel集群将从剩余的从节点中选举一个新的主节点，有以下步骤： 故障节点主观下线 故障节点客观下线 Sentinel集群选举Leader Sentinel Leader决定新主节点 选举过程 1、主观下线 Sentinel集群的每一个Sentinel节点会定时对redis集群的所有节点发心跳包检测节点是否正常。如果一个节点在down-after-m...
Redis哨兵模式主服务器宕机后每次选举选举仍然选挂掉的主服务器错误failover-state-select-slave master mymaster报错原因即解决方案
Menghu98621的博客
04-06 1827
报错原因：没有开放所有主从服务器和哨兵节点的端口。 解决方案：开放窗口或关闭防火墙：执行systemctl stop firewalld.service命令。
运维(24) docker-compose部署redis一主二从三哨兵模式
郑清
02-26 2067
文章目录一、前言二、docker-compose部署redis一主二从三哨兵模式docker-compose-redis-master-slave-sentinel.ymlredis.confredis-sentinel.conf三、测试四、其它解决情况1：端口映射问题解决情况2：redis由于安全问题禁用命令CONFIG - 防止客户端修改Redis配置解决情况3：redis主节点下线后再重启变成从节点时，需配置认证主节点 一、前言 运维(23) docker-compose部署redis主从复制模式 本
Redis第二十六讲 Redis哨兵心跳检测与哨兵leader选举流程
程序员路同学
04-14 830
Redis第二十六讲 Redis哨兵心跳检测与哨兵leader选举流程
Redis哨兵的选举细节
z1547497656的博客
05-24 1516
Redis哨兵的选举细节1、sdown和odown转换2、哨兵集群的自动发现3、slave配置的自动纠正4、slave->master选举算法5、quorum和majority6、configuration epoch7、configuraiton传播 1、sdown和odown转换 sdown和odown两种失败状态 sdown是主观宕机，就一个哨兵如果自己觉得一个master宕机了，那么就是主观宕机 odown是客观宕机，如果quorum数量的哨兵都觉得一个master宕机了，那么就是客观宕机 s
Redis中哨兵选举算法
weixin_44324174的博客
10-06 1万+
文章目录1、哨兵的三个定时任务2、 主观下线（SDOWN）和客观下线（ODOWN）3、选举Leader哨兵，来进行故障转移（1）Raft简单介绍（2） Term（任期）（3） RPC（4） 选举流程4、主节点选取5、故障转移 1、哨兵的三个定时任务 1、每个哨兵每10秒会向主节点和从节点发送info命令获取最新的拓扑结构图，哨兵配置时只需要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知。 2、每个哨兵节点每隔2秒会向redis数据节点的指定频道
详解Redis哨兵模式下，主节点掉线而重新选取主节点的流程
wyd_333的博客
02-04 3832
最核心的结论：所谓选举的过程不是直接选出新的主节点，而是先在哨兵节点中选出 leader ，再由 leader 负责后续主节点的指定。
redis主从复制，master挂掉之后sentinel（哨兵）不能自动选举新的master
inquesiting的博客
05-20 8138
三台服务器 分别部署三个redis 192.168.1.1 6379 (master) 192.168.1.2 6379 (slave) 192.168.1.3 6379 (slave) 当我把master shutdown后 sentinel 不能自动选举出新的master并，出现failover-abort-no-good-slave 错误 修改redis.conf 三...
Redis-master节点宕机后的处理方式
m0_54714490的博客
11-05 2116
在redis集群中，每个节点各司其职，有的当老大，有的当小弟，老大负责写，小弟负责读。但是如果老大挂了，这些小弟就群龙无首了，我们的服务就会崩盘，谁都不愿意这种事情发生，所以我们需要了解当master节点挂了之后redis的处置方式。如果第三项都一样，那么其实选哪个slave都一样，因为他们的数据都是最新的，都可以成为主节点，那么这时候就根据他们的id判断，id越小优先级越高。我们应该从slave节点中选举出一个新的master节点，并且让原来的slave节点的老大都变成这个新的老大。这里我们有一套标准。
Redis 集群模式下一个 Master 挂掉后如何选举？
gb4215287的博客
06-13 514
redis集群模式
Redis一主二从三哨兵模式
不知道
07-21 2907
当你使用Redis作为主从复制的架构，并且希望在出现主节点故障时自动进行故障转移时，适用于一主而从三哨兵模式在一主而从三哨兵模式中，有一个主节点和多个从节点，同时还有三个哨兵节点来监控主节点的健康状态。当主节点出现故障时，哨兵节点会自动选举一个从节点作为新的主节点，并将其他从节点切换到新的主节点上，这个过程是自动的，不需要手动干预。。这种架构可以提高系统的可用性和容错性。
六、Redis哨兵机制
jiayoubaobei2的博客
09-21 646
Redis哨兵机制
图解redis（四）——高可用篇
yttt的博客
10-02 1303
图解redis（四）——高可用篇
Redis 哨兵机制
挣扎中的码农
10-26 1090
Redis 哨兵机制 一．Redis 哨兵机制作用： 当redis主节点宕机时，redis哨兵节点会在从节点里选举出一个节点代替主节点，维持主从复制。避免了手动处理主节点故障，实现redis的高可用（高可用：通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性）。 二．Redis哨兵机制原理： Redis sentinel会对数据节点进行监控（通过ping命令），当发现节点...
redis如何配置哨兵集群?
bangiao的博客
06-14 534
哨兵存在的意义是redis主从集群没有共识算法, 或者说没有选举算法, 所以在master挂掉之后, 无法执行选举出一个新的master, 需要sentinel哨兵集群做监控sentinel哨兵集群使用心跳包的方法, 监听redis主从集群的状态, 通常是每秒1次, ping发现问题之后, 走故障转移流程, 通过选举出新的master, 然后切换master链接。
Redis_哨兵机制
Eric的博客
04-02 501
Redis_哨兵机制（Sentinel） 主从模式缺点，master节点挂了以后，redis就不能对外提供写服务了，因为剩下的slave不能成为master。所以一般的生产坏境是不会单单只有主从模式的。所以有了下面的sentinel模式。 1、概述 哨兵模式又称sentinel模式 ，sentinel的中文含义是哨兵、守卫。也就是说既然主从模式中，当master节点挂了以后，slave节点不...
redis 哨兵模式下，主节点挂掉如何选举从节点为主节点的
最新发布
03-17
<think>嗯，用户想了解Redis哨兵模式下，主节点宕机后从节点选举为主节点的流程。我需要先回顾一下Redis哨兵的相关知识，确保回答准确。 首先，哨兵集群的主要功能是监控主节点和从节点，当主节点不可用时，自动进行故障转移。这个过程包括几个关键步骤：检测主节点下线、选举哨兵领导者、选择新的主节点、切换配置和通知客户端。 根据引用[1]，哨兵节点会定期检查主节点的状态。如果超过半数的哨兵认为主节点主观下线（SDOWN），就会触发客观下线（ODOWN）。这时候需要开始故障转移流程。这里要注意，客观下线的判断需要多数哨兵的确认，避免误判。 接下来，选举哨兵领导者。引用[2]提到，哨兵之间使用Raft算法来选出一个领导者，由它来负责后续的故障转移操作。这一步很重要，因为只有领导者才能执行故障转移，确保操作的唯一性。 然后是选择新的主节点。引用[2]和[4]指出，领导者会根据从节点的健康状况、复制偏移量、优先级等因素进行评估。优先级高的从节点会被优先考虑，复制偏移量最新的节点数据更完整，所以这一步要综合考虑多个因素，确保选出最合适的从节点。 之后，领导者会发送slaveof no one命令给选中的从节点，使其成为新的主节点，并更新其他从节点和客户端的配置。这里可能遇到的问题如引用[3]和[4]提到的端口未开放或防火墙问题，导致故障转移失败，需要确保网络配置正确。 最后，通知客户端新的主节点地址，并持续监控旧主节点，以防它恢复后作为从节点加入集群。这部分在引用[1]和[3]中有提到，配置文件的正确设置和网络可达性很重要。 用户可能还想知道选举中的细节，比如如何避免多个领导者，或者如何处理网络分区的问题。另外，实际应用中可能遇到的配置错误，比如bind设置或防火墙问题，需要根据引用[3]和[4]的建议来解决。 总结回答时，要分步骤清晰地解释流程，引用相关参考资料，并指出常见问题及解决方法，这样用户能全面理解整个过程。</think>### Redis哨兵模式主节点故障转移流程解析 Redis哨兵模式下主节点宕机后的从节点选举流程可分为以下关键步骤，结合引用内容中的技术细节进行说明： 1. **检测主节点故障** - 每个哨兵节点每隔1秒向主节点发送`PING`命令（默认配置） - 当主节点连续无响应超过`down-after-milliseconds`阈值（默认30秒），哨兵将其标记为**主观下线(SDOWN)** - **客观下线(ODOWN)** 需要满足：`quorum`数量（配置参数）的哨兵节点都确认主节点不可用[^1][^4] - 触发故障转移的条件：多数哨兵节点达成共识（哨兵总数/2 +1） 2. **选举哨兵领导者** - 使用Raft算法在哨兵节点间选举出领导者（Leader），只有领导者能执行故障转移[^2] - 选举规则： - 每个发现主节点ODOWN的哨兵会发起投票请求 - 先到先得的投票机制，最先达到多数票的哨兵成为Leader - 每个纪元(epoch)只产生一个Leader 3. **筛选候选从节点** - 领导者哨兵根据以下标准评估从节点： ```python # 伪代码评估逻辑 def select_slave(slaves): valid_slaves = [s for s in slaves if s.info_repl_age < 60 # 数据同步延迟 and s.last_ack_time < 5000 # 最近响应时间 and s.slave_priority > 0] # 优先级配置 # 按优先级排序，相同优先级比复制偏移量 return sorted(valid_slaves, key=lambda x: (-x.slave_priority, -x.repl_offset)) ``` - 排除条件： - 长时间未响应（超过`repl-timeout`配置） - 复制偏移量过时（与主节点差异超过阈值） - 手动配置`slave-priority=0`的节点不参与选举[^2] 4. **执行故障转移** - 领导者向目标从节点发送`SLAVEOF NO ONE`命令，将其提升为主节点 - 更新哨兵集群的拓扑信息： ```shell # 修改新主节点的配置 config set slave-read-only no # 通知其他从节点复制新主节点 sentinel failover <master-name> ``` - 更新所有哨兵的`sentinel.conf`，记录新主节点信息 5. **客户端重定向** - 哨兵通过`+switch-master`事件通知客户端 - 客户端订阅`__sentinel__:hello`频道获取新主节点地址 - 旧主节点恢复后会被哨兵自动设置为新主节点的从节点[^1] **常见问题解决方案**： - 故障转移失败时检查： 1. 确保所有节点间端口开放（6379+16379）[^3] 2. 配置文件添加`bind 0.0.0.0`允许跨服务器通信 3. 关闭防火墙或设置正确规则： ```shell systemctl stop firewalld.service # CentOS ufw allow 6379/tcp # Ubuntu ```
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值