Redis哨兵模式配置：主从切换与故障验证实操

Redis哨兵模式配置的核心是：先让一台Redis做主、其他做从，再启动奇数个Sentinel进程监控这套主从，当主节点宕机时由Sentinel投票选出新主并通知客户端。
下面按三台服务器（一主两从三哨兵）的最简可用方案展开，适合零基础照着做。

部署前的环境和文件准备

需要准备至少3台能互通的主机，Redis版本建议5.0以上，Sentinel从2.8起已稳定。
本文以Redis 6.2为例，路径统一用/usr/local/redis。

先确认三台机器时间同步、防火墙放行端口，并约定角色：

• 192.168.1.10：Redis主节点 + Sentinel
• 192.168.1.11：Redis从节点 + Sentinel
• 192.168.1.12：Redis从节点 + Sentinel

安装Redis可以用系统包或源码编译。
源码方式示例：

cd /usr/local
wget https://download.redis.io/releases/redis-6.2.14.tar.gz
tar -xzf redis-6.2.14.tar.gz
ln -s redis-6.2.14 redis
cd redis
make && make install
mkdir -p /usr/local/redis/conf /usr/local/redis/data /usr/local/redis/log

编译完成后，redis-server、redis-cli、redis-sentinel三个可执行文件会安装到/usr/local/bin。
执行redis-server -v能输出版本号即表示安装成功。

先搭主从：让数据能复制过去

主节点192.168.1.10上的redis.conf关键项：

bind 0.0.0.0
protected-mode no
port 6379
daemonize yes
pidfile /var/run/redis_6379.pid
logfile "/usr/local/redis/log/redis_6379.log"
dir /usr/local/redis/data
requirepass YourStrongPass123
masterauth YourStrongPass123
appendonly yes

requirepass是客户端连接密码，masterauth是从节点连主节点时用的密码，两者保持一致，否则主从复制会因认证失败中断。

从节点192.168.1.11和192.168.1.12的配置在主节点基础上增加一行：

replicaof 192.168.1.10 6379

三台分别启动：

redis-server /usr/local/redis/conf/redis.conf

在主节点上执行redis-cli -a YourStrongPass123 info replication，看到role:master且connected_slaves:2说明主从复制已建立。
如果connected_slaves为0，先检查从节点日志里的MASTER <-> REPLICA sync记录。

编写sentinel.conf并启动哨兵

Sentinel有独立配置文件，不能和redis.conf混用。
三台机器内容基本一致，只有myid和日志路径可区分。
示例/usr/local/redis/conf/sentinel.conf：

port 26379
daemonize yes
logfile "/usr/local/redis/log/sentinel_26379.log"
dir /usr/local/redis/data
sentinel monitor mymaster 192.168.1.10 6379 2
sentinel auth-pass mymaster YourStrongPass123
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

几个参数必须理解，否则切换行为会不符合预期：

• sentinel monitor mymaster 192.168.1.10 6379 2：监控名为mymaster的主节点，最后的2表示至少2个Sentinel都认为主节点下线才触发故障转移，这个值通常设为Sentinel总数的一半加一。
• sentinel auth-pass mymaster YourStrongPass123：Sentinel连主从节点用的密码，Redis设了requirepass就必须写这一行，否则Sentinel无法获取主从状态。
• down-after-milliseconds：主观下线判定时间，单位毫秒，设太小会因网络抖动误判，设太大会延长切换时间。

用redis-sentinel或redis-server启动都可以：

redis-sentinel /usr/local/redis/conf/sentinel.conf

三台都启动后，在任意一台执行：

redis-cli -p 26379 sentinel master mymaster

输出中num-other-sentinels应为2，表示另外两个哨兵已被发现。
如果为0，检查哨兵之间26379端口是否互通。

模拟主节点宕机，验证自动切换

先记录当前主节点：

redis-cli -p 26379 sentinel get-master-addr-by-name mymaster

然后在主节点192.168.1.10上停掉Redis：

redis-cli -a YourStrongPass123 shutdown

等待约down-after-milliseconds加切换时间（通常5到15秒），再次查询主节点地址，应该变成192.168.1.11或192.168.1.12。
同时查看哨兵日志：

tail -f /usr/local/redis/log/sentinel_26379.log

日志中会出现+sdown（主观下线）、+odown（客观下线）、+switch-master等事件，看到+switch-master即表示切换完成。

原来的主节点恢复后，Sentinel会自动把它变成新主的从节点，不需要手动改replicaof。

常见报错和避坑要点

哨兵启动后num-other-sentinels为0：多数是防火墙拦截26379端口，或bind只绑了127.0.0.1。
确认bind 0.0.0.0且安全组放行。

切换后客户端仍连旧主：Sentinel不会主动修改客户端配置，客户端必须使用支持哨兵的连接方式（如Jedis的JedisSentinelPool、Lettuce的RedisSentinelConfiguration），通过Sentinel地址获取当前主节点。
直接写死IP的程序切换后必然失败。

主从复制中断，日志报NOAUTH：masterauth和主节点requirepass不一致。
两处密码必须相同，且修改后要重启对应实例。

不要用偶数个Sentinel：2个哨兵时，一个宕机就无法达到多数票，故障转移会卡住。
生产环境建议3个或5个，分布在不同的物理机上。

sentinel.conf会被自动重写：Sentinel运行期间会修改配置文件，记录已知的哨兵和从节点信息。
不要手动编辑正在运行的sentinel.conf，需要改参数时先停哨兵再改。

配置是否生效的检查清单

部署完成后，按下面几项逐条确认，比只看启动日志更可靠：

• 主节点info replication显示connected_slaves数量与从节点数一致；
• 每个哨兵执行sentinel master mymaster，num-other-sentinels为其他哨兵数量；
• 手动shutdown主节点，get-master-addr-by-name返回的地址发生变化；
• 旧主恢复后自动成为新主的从节点，info replication中role:slave；
• 客户端通过Sentinel地址连接，不依赖固定主节点IP。

如果以上都通过，Redis哨兵模式配置就算完成。
后续扩容从节点只需在从节点配置replicaof并重启，Sentinel会自动纳入监控。

读者常问的几个问题

哨兵和主从复制是什么关系？ 主从复制只解决数据冗余和读扩展，主节点挂了不会自动切换。
哨兵是在主从之上增加监控和投票机制，负责选新主、通知客户端，两者配合才构成高可用方案。

最少需要几台机器？ 哨兵要求多数票，至少3个Sentinel实例。
可以3个Sentinel和3个Redis混部在3台机器上，但生产环境建议Sentinel与Redis分开部署，避免一台机器故障同时影响两种角色。

Sentinel能替代Cluster吗？ 不能。
Sentinel管理的是主从架构，数据仍全量存在每个节点；
Cluster做的是分片，解决单机内存上限。
数据量超过单机内存时选Cluster，只是要主从高可用选Sentinel。

修改了Redis密码后哨兵连不上怎么办？ 需要同步修改每个sentinel.conf中的sentinel auth-pass，然后重启所有Sentinel。
只改Redis不改哨兵，切换时会因认证失败无法完成。