Redis哨兵模式Redis 哨兵模式 Redis 里如果主节点挂了怎么办，怎么完成业务切换与故障转移呢，这一期主要讲解

Redis 哨兵模式

Redis 里如果主节点挂了怎么办，怎么完成业务切换与故障转移呢，这一期主要讲解 Redis 的哨兵机制。

哨兵（Sentinel）：独立进程，监控 Redis 主从健康状态，自动选举新主节点（类似"保安团队"）。
故障转移（Failover）：主节点故障时，哨兵自动提升从节点为新主节点。

本节理论部分简单带过，在实战里理解。

实战

一、环境准备

1. 三台 Rocky 8.10 服务器：

主机	IP	角色
node1	192.168.171.147	Redis 从节点
node2	192.168.171.148	Redis 主节点
node3	192.168.171.146	Redis 从节点

所有节点执行，安装依赖：

dnf install -y gcc make tcl wget

2. Redis 源码安装（所有节点）：

# 下载源码包
wget http://download.redis.io/releases/redis-7.2.0.tar.gz -P /opt
tar -zxvf /opt/redis-7.2.0.tar.gz
cd /opt/redis-7.2.0 && make && make install

# 创建配置文件目录
mkdir -p /usr/local/redis/{conf,data,log}
cp /opt/redis-7.2.0/redis.conf /usr/local/redis/conf/

二、配置部署

1. 配置主节点（node2：192.168.171.148）

vim /usr/local/redis/conf/redis.conf

bind 0.0.0.0
port 6379
daemonize yes    # Redis 配置文件中控制是否以守护进程（后台进程）方式运行的选项
logfile "/usr/local/redis/log/redis.log"
dir /usr/local/redis/data
requirepass your_password    # 设置密码，主从需一致！

配置好后启动主节点，再用 info replication 检查状态：

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

2. 配置从节点

vim /usr/local/redis/conf/redis.conf

replicaof 192.168.171.148 6379    # 指向主节点 IP 和端口
masterauth your_password           # 主节点密码

再启动从节点，用 info replication 检查从节点状态：

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

最好再数据检验一下主从同步，这里略过。

3. 配置哨兵（所有节点）

vim /usr/local/redis/conf/sentinel.conf

port 26379
daemonize yes
logfile "/usr/local/redis/log/sentinel.log"
sentinel monitor mymaster 192.168.171.148 6379 2   # 监控主节点，2 为 quorum 值
sentinel auth-pass mymaster your_password
sentinel down-after-milliseconds mymaster 5000     # 5 秒无响应判定为故障
sentinel failover-timeout mymaster 10000           # 故障转移超时时间

quorum 值：1 是判定主节点客观下线所需的最少哨兵数量（quorum）。

配置好以后启动哨兵（所有节点）：

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

使用 info sentinel 命令查看哨兵状态：

redis-cli -p 26379 info sentinel

4. 模拟宕机测试哨兵

在主节点执行：

redis-cli -h 192.168.171.148 shutdown

观察哨兵日志（要在活着的节点上观察）：

tail -f /usr/local/redis/log/sentinel.log    # 查看选举新主过程

验证新主节点：

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

注：Redis Sentinel 故障转移后，会自动重写哨兵配置文件，把主节点地址改成新选举出来的主节点。

5. 原主节点恢复后会怎么样

恢复过程的三个阶段：

阶段	会发生什么	日志关键字
① 刚起来	它按自己的 `redis.conf` 启动。因为配置文件里没有 `replicaof`，所以它一开始还是 `role:master`	—
② 哨兵发现它	哨兵周期性发 `INFO` / `PING`，发现"原主回来了，但它不是新主的从"	`-sdown slave <ip>:6379`（不再是下线状态）
③ 哨兵降级它	哨兵直接发 `SLAVEOF <新主IP> <端口>` 命令，把它变成从节点	`+convert-to-slave slave <ip>:6379 ...`

但是哨兵降级是运行时降级 —— 能自动改写 sentinel.conf，但是不能修改 Redis 的配置文件：

哨兵发的是 REPLICAOF 命令（运行时生效），它不会去改原主节点的 redis.conf。

所以你会看到这个现象：
   运行时    ：role:slave          ← 哨兵降级的结果
   配置文件  ：没有 replicaof      ← 文件根本没被动过

★ 后果：如果你这时候【重启】原主节点的 Redis，
        它会按配置文件重新变成 master，
        然后哨兵发现后【再降级一次】。
        这个"反复"是正常现象，不是故障。

数据角度，原节点又会发生什么：

场景：主节点故障那一瞬间，客户端刚写了一条数据，还没同步给从节点
      → 这条数据只存在于原主上

恢复后：
   原主变成从节点 → 执行全量同步 → 【先清空自己】→ 再从新主拉 RDB
                                          │
                                          └─ 那条"独有"的数据就丢了

★ 这是异步复制的固有代价 —— 哨兵保证的是【服务可用】，
  不是【数据零丢失】。

那怎么解决异步同步带来的问题呢？

三、故障转移日志排查表

日志行	含义
`+sdown master mymaster <IP> <端口>`	主观下线 —— 某个哨兵认为主节点没响应了
`+odown master mymaster <IP> <端口>`	客观下线 —— 认为下线的哨兵达到了 quorum（2 个）
`+elected-leader master mymaster ...`	选举出一个领头哨兵来执行故障转移
`+failover-state-select-slave master ...`	开始挑选新主
`+selected-slave slave <IP>:6379 ...`	选中了某个从节点当新主
`+failover-state-send-slaveof-noone ...`	让选中的从节点脱离主从、成为独立主节点
`+switch-master mymaster <旧主IP> <端口> <新主IP> <端口>`	★ 切换完成 —— 主节点换了
`+convert-to-slave slave <原主IP>:6379 ...`	★ 原主恢复后被降级为从节点
`-sdown slave <IP>:6379`	某个从节点不再是"下线"状态（恢复上线了）