请教redis sentinel 无法failover 的问题

Posted 2023-04-05

描述太少，无法判断。最好查看sentinel的日志分析问题。

可能的原因有：

主从关系没有配置好，主机down掉后，sentinel会在从机中选择一个切换，如果没有从机或者主从没有配置好，那么无法failover。

主从和从机的密码问题，sentinel进行failover时，要连接从机，如果主机、从机、sentinel配置的auth-pass不一致，就会出现验证失败从而导致failover失败。

参考技术A 具体问题呢

Redis哨兵模式(Sentinel)的搭建

一、Redis的哨兵模式

      Sentinel是Redis官方提供的一种高可用方案（除了Sentinel，Redis Cluster是另一种方案），它可以自动监控Redis master/slave的运行状态，如果发现master无法访问了，就会启动failover把其中一台可以访问的slave切换为master，并且通过pub/sub事件通知Redis客户端新的master的ip地址。

      支持Sentinel的Redis客户端（例如java的Jedis）会在连接Redis服务器的时候向Sentinel询问master的ip，并且会在收到master切换的pub/sub事件后自动重新连接到新的master。对调用Redis客户端的业务系统来说，这些都是完全透明的。通过设置一组哨兵sentinel，监控Master的运行，当Master不可用时，自动完成上述的动作，而不需人工干预。下图就是哨兵模式。每个哨兵sentinel会向其它sentinal、master、slave定时发送消息，以确认对方是否“活”着，如果发现对方在指定时间（可配置）内未回应，则暂时认为对方已挂（所谓的“主观认为宕机” Subjective Down，简称SDOWN）。

   

   

若“哨兵群”中的多数sentinel，都报告某一master没响应，系统才认为该master"彻底死亡"(即：客观上的真正down机，Objective Down，简称ODOWN)，通过一定的vote算法，从剩下的slave节点中，选一台提升为master，然后自动修改相关配置。

1、当redis master down了以后

2、监控到N个sentinel无法访问master

3、哨兵进程发起投票启动failover，投票结果为由其中一个哨兵进程发起failover

4、更新sentinel和slave的配置，将slave升级成master

5、向JedisClient发送master切换事件，jedis将访问新的master

二、Redis3.2.3哨兵模式的配置

两台机器：12.99.105.205和12.99.105.206；

一主一从：master 12.99.105.205:6379，slave 12.99.105.206:6379；

三个哨兵进程：12.99.105.205:26379,12.99.105.206:26379,12.99.105.206:26380。

使用root用户 修改 /etc/security/limits.conf文件，新增以下信息

redis hard nofile  30000
redis soft  nofile  30000

使用/usr/local/redis-3.2.3/data/作为数据目录，分配100G以上的空间

master的配置

daemonize yes
port 6379
pidfile "/usr/local/redis-3.2.3/data/redis.pid"
tcp-keepalive 60
logfile "usr/lcoal/redis-3.2.3/logs/redis.log"
dir "/user/local/redis-3.2.3/data"
masterauth "123456"
requirepass "123456"
appendonly yes

slave的配置

daemonize yes
port 6379
pidfile "/usr/local/redis-3.2.3/data/redis.pid"
tcp-keepalive 60
logfile "usr/lcoal/redis-3.2.3/logs/redis.log"
dir "/user/local/redis-3.2.3/data"
masterauth "123456"
requirepass "123456"
appendonly yes
slaveof 12.99.105.205 6379

slave与master的配置区别在于slave多了一行”slaveof 12.99.105.205 6379”。

12.99.105.205哨兵的配置为

port 26379
daemonize yes
pidfile "/usr/local/redis-3.2.3/data/sentinel.pid"
logfile "/usr/local/redis-3.2.3/sentinel.log"
protected-mode no
sentinel monitor mymaster 12.99.105.205 6379 2

12.99.105.206哨兵1的配置为

port 26379
daemonize yes
pidfile "/usr/local/redis-3.2.3/data/sentinel.pid"
logfile "/usr/local/redis-3.2.3/sentinel.log"
protected-mode no
sentinel monitor mymaster 12.99.105.205 6379 2

12.99.105.206哨兵2的配置为

port 26380
daemonize yes
pidfile "/usr/local/redis-3.2.3/data/sentinel.pid"
logfile "/usr/local/redis-3.2.3/sentinel.log"
protected-mode no
sentinel monitor mymaster 12.99.105.205 6379 2

哨兵的配置是一样的，唯一的区别是端口的差异。

sentinel monitor mymaster 12.99.105.205 6379 2

这一行的配置是最重要的，表示它监听的是哪个master，2表示3个哨兵中有2个哨兵认为符合启动failover的条件，才会启动failover，防止失误。

Java应用连接redis3.2.3主从集群需要使用commons-pool2-2.2.jar和jedis-2.8.0.jar，

Redis连接池初始化的代码如下，由于sentinel知道关于主从集群的一切信息（包括哪个是master，哪个slave），所以连接池初始化时，只需要把哨兵的信息传进去就可以了。

 1 Set<String> sentinelSet = new HashSet<String>();
 2 String[] sentinels = new String[]{"12.99.105.205:26379","12.99.105.206:26379","12.99.105.206:26380"};
 3 for(int i=0;i<sentinels.length;i++){
 4     sentinelSet.add(sentinels[i]);
 5 }
 6 String masterName="mymaster";
 7 String password="123456";
 8 int timeout=2000;
 9 
10 JedisPoolConfig poolConfig=new JedisPoolConfig();
11 poolConfig.setMaxTotal(300);
12 poolConfig.setMaxIdle(200);
13 poolConfig.setTestOnBorrow(true);
14 poolConfig.setTestWhileIdle(false);
15 
16 Pool<Jedis> pool = new JedisSentinelPool(masterName,sentienlSet,poolConfig,timeout,password);

三、Redis3.2.3哨兵模式的验证

      测试程序应用通过Jedis不断地向redis主从集群set和get，当kill掉redis master 的进程，应用会出现短暂的报错（约30到40秒），之后又恢复正常。在这30~40秒的时间内，哨兵进程发起failover，更新sentinel、slave和原master的配置，将slave升级成master。