问题：

Redis多哨兵失败后不选举新的Redis大师

苗征

2023-03-14

我有一个三个节点redis和三个节点sentinel，一切正常，所有主和从都被验证，哨兵配置文件被更新所有redis和sentinel节点，但问题是当redis主关闭和sentinel想再次选择失败的主，而不是在其他从之间选择新的主，这里是我的配置文件和日志。

VM1:redis master and sentinel1 192.168.1.48

VM2:redis slave and sentinel2 192.168.1.51

VM3:redis slave and sentinel3 192.168.1.52

bind 192.168.1.48 127.0.0.1 
protected-mode yes
port 6379
tcp-backlog 511
timeout 0
tcp-keepalive 60
daemonize no
supervised systemd 
pidfile /var/run/redis_6379.pid
loglevel notice
logfile ""
databases 16
always-show-logo yes
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir /var/lib/redis 
replica-serve-stale-data yes
replica-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
replica-priority 100
requirepass 123456789
lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
replica-lazy-flush no
appendonly no
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
aof-use-rdb-preamble yes
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-size -2
list-compress-depth 0
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
stream-node-max-bytes 4096
stream-node-max-entries 100
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit replica 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
dynamic-hz yes
aof-rewrite-incremental-fsync yes
rdb-save-incremental-fsync yes

#1
bind 0.0.0.0
port 26379
#2
sentinel myid 7e09f70bc68cdc0afee3d8cd9bdf3fe6f320a3d5
sentinel deny-scripts-reconfig yes
sentinel monitor redis-cluster 192.168.1.48 6379 3
sentinel down-after-milliseconds redis-cluster 5000
#3
sentinel failover-timeout redis-cluster 1000
sentinel parallel-syncs redis-cluster 1

#misc
daemonize yes
pidfile "/var/run/redis_26379.pid"
logfile "/var/log/redis_26379.log"
dir "/var/lib/redis"

##############
# Generated by CONFIG REWRITE
protected-mode no
sentinel auth-pass redis-cluster 123456789
sentinel config-epoch redis-cluster 0
sentinel leader-epoch redis-cluster 52
sentinel known-replica redis-cluster 192.168.1.51 6379
sentinel known-replica redis-cluster 192.168.1.52 6379
sentinel known-sentinel redis-cluster 192.168.1.52 26379 0b37aa7287e89ad38a90a97cdff16c22793678a6
sentinel known-sentinel redis-cluster 192.168.1.51 26379 9d097bb22ffdf87c7f8a403a8dc82c989790cf3b
sentinel current-epoch 52

#1
bind 0.0.0.0
port 26379
#2
sentinel myid 9d097bb22ffdf87c7f8a403a8dc82c989790cf3b

daemonize yes
pidfile "/var/run/redis_26379.pid"
sentinel deny-scripts-reconfig yes
sentinel monitor redis-cluster 192.168.1.48 6379 2
sentinel down-after-milliseconds redis-cluster 5000
sentinel failover-timeout redis-cluster 10000
#3
sentinel auth-pass redis-cluster 123456789
#misc
logfile "/var/log/redis_26379.log"
dir "/var/lib/redis"
# Generated by CONFIG REWRITE
protected-mode no
sentinel config-epoch redis-cluster 0
sentinel leader-epoch redis-cluster 28811
sentinel known-replica redis-cluster 192.168.1.51 6379
sentinel known-replica redis-cluster 192.168.1.52 6379
sentinel known-sentinel redis-cluster 192.168.1.52 26379 0b37aa7287e89ad38a90a97cdff16c22793678a6
sentinel known-sentinel redis-cluster 192.168.1.48 26379 7e09f70bc68cdc0afee3d8cd9bdf3fe6f320a3d5
sentinel current-epoch 28811

主机故障后的哨兵日志:(vm2)

2692:X 15 Jan 2020 09:19:42.576 # +vote-for-leader 0b37aa7287e89ad38a90a97cdff16c22793678a6 28804
2692:X 15 Jan 2020 09:19:42.582 # Next failover delay: I will not start a failover before Wed Jan 15 09:20:02 2020
2692:X 15 Jan 2020 09:20:02.659 # +new-epoch 28805
2692:X 15 Jan 2020 09:20:02.660 # +try-failover master redis-cluster 192.168.1.48 6379
2692:X 15 Jan 2020 09:20:02.662 # +vote-for-leader 9d097bb22ffdf87c7f8a403a8dc82c989790cf3b 28805
2692:X 15 Jan 2020 09:20:02.674 # 0b37aa7287e89ad38a90a97cdff16c22793678a6 voted for 9d097bb22ffdf87c7f8a403a8dc82c989790cf3b 28805
2692:X 15 Jan 2020 09:20:02.745 # +elected-leader master redis-cluster 192.168.1.48 6379
2692:X 15 Jan 2020 09:20:02.745 # +failover-state-select-slave master redis-cluster 192.168.1.48 6379
2692:X 15 Jan 2020 09:20:02.846 # -failover-abort-no-good-slave master redis-cluster 192.168.1.48 6379
2692:X 15 Jan 2020 09:20:02.902 # Next failover delay: I will not start a failover before Wed Jan 15 09:20:22 2020

共有1个答案

柯波娃

2023-03-14

我明白这个答案有点晚了，但是，这里有一些我的经验的见解

这里的问题在于从优先级。

有许多条件取决于主人选举发生。

一旦满足以上所有条件，节点就会按照优先级的顺序担任主节点的角色。

PS：除了上面的内容，redis还添加了一些额外的逻辑，使决策更加可靠和可靠，请在官方文档中找到更多信息

类似资料：

v Redis 哨兵

Redis 哨兵（Sentinel）是 Redis 的高可用性（Hight Availability）解决方案：由一个或多个 Sentinel 实例组成的 Sentinel 系统可以监视任意多个主服务器，以及这些主服务器的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。 Sentinel
Redis哨兵模式

主要内容：哨兵模式原理,哨兵模式应用,sentinel.conf配置项在 Redis 主从复制模式中，因为系统不具备自动恢复的功能，所以当主服务器（master）宕机后，需要手动把一台从服务器（slave）切换为主服务器。在这个过程中，不仅需要人为干预，而且还会造成一段时间内服务器处于不可用状态，同时数据安全性也得不到保障，因此主从模式的可用性较低，不适用于线上生产环境。 Redis 官方推荐一种高可用方案，也就是 Redis Sentinel 哨兵模式，它弥补了主
带TLS的Redis哨兵

Redis4.x是否兼容使用Sentinels运行TLS？我发现一些线程提到对TLS的支持将被添加到3.2中，但没有任何证实。
Redis 3.2哨兵不工作

我的Redis Sentinel故障转移不起作用，当master完成时，不进行握手，故障转移也不发生；然而，sentinel会显示主程序何时恢复到正常状态或何时关闭。我的sentinel.conf文件内容如下：我真的很感激你能帮上忙。
Redis哨兵不会自动发现其他哨兵

每一个哨兵都可以连接到我的主人，并可以看到奴隶。它们能够独立地检测主从是否倒下。问题是哨兵们无法探测到对方。我已经验证了每个哨兵都像预期的那样向通道发布消息，但似乎没有一个哨兵真正从其他哨兵通道接收消息。我怎么让哨兵们见面？
重命名redis的配置命令后，哨兵工作失败

我已经安装了最稳定的redis(Ver3.2)。一切都很好，直到我重新命名了redis的配置命令，哨兵不能把奴隶提升为主人。认为问题是哨兵仍然使用CONFIG命令（已经重命名）来改变Redis的配置。是否有任何方法来改变sentinel的配置（通过redis-cli或配置文件sentinel.conf）以适应redis配置（重命名为config命令）。如果没有，那么改变源代码怎么样？谢谢

Redis多哨兵失败后不选举新的Redis大师

共有1个答案

相关问答

相关文章

相关阅读

相关工具

相关文档