【redis哨兵】Failed listening on port 26379 (TCP)&&哨兵模式没反应问题解决

本文介绍了Redis哨兵系统在监听端口被占用、配置不当以及出现'broken pipe'错误时的处理方法。针对端口冲突问题,通过终止并重启哨兵进程解决了端口占用;对于哨兵模式无响应,调整配置中主从切换的确认数,确保选举过程能正常进行;而对于'broken pipe'问题,理解为正常信息更新延迟,无需特别处理。这些解决步骤有助于维护Redis集群的稳定运行。
摘要由CSDN通过智能技术生成

问题1 Failed listening on port 26379 (TCP)

报错信息如下,遇到这种问题一般都是由于端口被占用所导致的,杀死哨兵进程后再重启一个哨兵进程即可

root@SD-20190801TIWK:/usr/local/bin# redis-sentinel myredisconfig/sentinel.conf
423:X 28 Feb 2022 09:22:32.725 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
423:X 28 Feb 2022 09:22:32.725 # Redis version=6.2.6, bits=64, commit=00000000, modified=0, pid=423, just started
423:X 28 Feb 2022 09:22:32.725 # Configuration loaded
423:X 28 Feb 2022 09:22:32.726 * Increased maximum number of open files to 10032 (it was originally set to 1024).
423:X 28 Feb 2022 09:22:32.726 * monotonic clock: POSIX clock_gettime
423:X 28 Feb 2022 09:22:32.726 # Warning: Could not create server TCP listening socket 127.0.0.1:26379: bind: Address already in use
423:X 28 Feb 2022 09:22:32.726 # Failed listening on port 26379 (TCP), aborting.
ps -ef|grep redis //查看哨兵进程
kill -9 哨兵进程号

在这里插入图片描述
此时就可以正常开启哨兵进程了。

问题2 哨兵模式没反应

在这里插入图片描述
这种问题一般是由于配置文件的设置问题,下面绿框中的2代表当有2个哨兵监测到master宕机了,才会真的认为它死了,而我这里只用了一个哨兵,所以这里设成2,它就会一直等别的哨兵的认定,导致重新选举这个步骤一直发生不了。改成1后错误解决
在这里插入图片描述

模拟6379宕机

在这里插入图片描述
在这里插入图片描述

改完后,重新选举过程就能正常执行了

在这里插入图片描述
在这里插入图片描述

江山易主,6380篡位成功

在这里插入图片描述

在这里插入图片描述

6379复活也只能是6380的slave

现在再让6379复活,会发现它已经不再是master,而是成为了6380的slave。
在这里插入图片描述

问题3-broken pipe

这种问题不用解决,更新信息本来就需要一定时间~~~
在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值