redis 哨兵模式开启方案

环境准备

• 准备三台系统为CentOS7的主机
  • master：192.168.152.71
  • slave1：192.168.152.72
  • slave2：192.168.152.73
    .
• 哨兵模式的介绍：
  • Redis 哨兵模式（Redis Sentinel）用于提供高可用性和监控功能，主要包括以下几个方面的作用：
    1. 监控: 哨兵模式会不断监控主节点和从节点的健康状况。如果主节点出现故障，哨兵能够检测到并进行处理。
    2. 自动故障转移: 当哨兵发现主节点不可用时，会自动将一个从节点升级为新的主节点，确保服务的持续可用性。
    3. 配置更新: 故障转移后，哨兵会更新所有从节点的配置，使它们指向新的主节点，从而保证系统的一致性和可靠性。
    4. 通知: 哨兵模式可以向系统管理员或其他应用程序发送主节点故障和状态变更的通知，帮助管理员及时了解系统状态。
    5. 客户端重定向: 在主节点发生故障转移后，哨兵能够通知客户端新的主节点的地址，使客户端能够重新连接到正确的节点。

一 、配置 sentinel 模式

再设置哨兵模式前请先确认，已经开启了主从复制 redis 主从复制方案

1. 进入 redis 的安装目录，找到 sentinel.conf 文件

   cd /opt/redis-4.0.9/
   vim ./sentinel.conf
   

   再三台主机的该文件中修改一下配置

   改 17 行 # protected-mode no 为；解掉注释即可

   protected-mode no  # 关闭保护模式
   

   改 69 行 sentinel monitor mymaster 127.0.0.1 6379 2 为

   sentinel monitor mymaster 192.168.152.71 6379 2
   
   # mymaster：这是监控的主节点的名字。你可以用任何你喜欢的名字来代替 mymaster，它将用于在哨兵中标识该主节点。
   # 192.168.152.71：这是主节点的 IP 地址，哨兵将监控这个地址上的主节点。
   # 6379：这是主节点的端口号，哨兵将连接到这个端口来监控主节点。
   # 2：这是故障转移的阈值，表示当哨兵检测到主节点不可用时，至少需要 2 个哨兵实例（超过半数的哨兵）确认主节点的故障，才能执行故障转移操作。
   

   改 98 行 sentinel down-after-milliseconds mymaster 30000 为

   sentinel down-after-milliseconds mymaster 3000
   
   # mymaster：这是你在 sentinel monitor 命令中配置的主节点名称，哨兵将对这个主节点应用下线判定规则。
   # 3000：这是哨兵判定主节点为“下线”所需的时间阈值，单位是毫秒。这里设置为 3,000 毫秒（即 3 秒）。如果哨兵在这个时间窗口内没有收到来自主节点的有效响应，哨兵就会将主节点标记为下线。这里设置 3 秒是为了更快的测试，实际为默认值即可
   

   • 注意事项：
     • 较短的时间阈值：设置为 3 秒是比较短的时间阈值。虽然这可以更快地检测到主节点的故障，但也可能导致在网络不稳定或瞬时问题时误判故障。这样可能会导致不必要的故障转移操作，影响系统的稳定性和性能。
     • 配置合理性：在实际部署中，应根据网络环境、系统负载和故障恢复需求合理配置该值。一般情况下，30000 毫秒（30 秒）是比较常见的设置，确保在判断故障之前有足够的时间来处理暂时的网络波动或延迟。

   改 131 行 sentinel failover-timeout mymaster 180000 为

   sentinel failover-timeout mymaster 10000
   
   # mymaster：这是你在 sentinel monitor 命令中配置的主节点名称。这个命令设置的是针对这个主节点的故障转移超时时间。
   # 10000：这是故障转移超时时间，单位是毫秒。这里设置为 10 秒。这表示在故障转移过程中的各种操作（如故障确认、从节点提升为主节点、配置更新等）必须在 10 秒内完成。如果在这个时间内无法完成所有故障转移操作，故障转移过程可能会被中止或者重新尝试。具体设置可以根据你的系统环境和需求进行调整。
   

2. 启动 sentinel 模式

   redis-sentinel sentinel.conf > /var/log/redis.log 2>&1 &
   

   可以通过 jobs 命令查看，通过 kill 命令关闭

二、测试

启动之后查看 redis.log 日志

sentinel日志输出的状态信息

• +reset-master ：主服务器已被重置
• +slave ：一个新的从服务器已经被 Sentinel 识别并关联。
• +failover-state-reconf-slaves ：故障转移状态切换到了 reconf-slaves 状态。
• +failover-state-select-slave ：故障转移操作现在处于 select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器。
• failover-state-send-slaveof-noone ：Sentinel 正在将指定的从服务器升级为主服务器，等待升级功能完成。
• failover-end-for-timeout ：故障转移因为超时而中止
• failover-end ：故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了
• no-good-slave ：Sentinel 操作未能找到适合进行升级的从服务器。Sentinel 会在一段时间之后再次尝试寻找合适的从服务器来进行升级，又或者直接放弃执行故障转移操作。
• +sentinel ：一个监视给定主服务器的新 Sentinel 已经被识别并添加。
• +sdown ：给定的实例现在处于主观下线状态。
• -sdown ：给定的实例已经不再处于主观下线状态。
• +odown ：给定的实例现在处于客观下线状态。
• -odown ：给定的实例已经不再处于客观下线状态。

停止master主机，看是否转换

+switch-master mymaster 192.168.152.71 6379 192.168.152.73 6379
# master主机从 192.168.152.71 切换到 192.168.152.73