当前位置： 首页 > news >正文

Redis 3.x——哨兵开发与运维中的问题

news 2026/7/17 1:09:49

哨兵开发与运维中的问题

    • 1、故障转移日志分析
      • 1.1、Redis Sentinel拓扑结构
      • 1.2、开始故障转移测试
      • 1.3、观察效果
      • 1.4、故障转移分析
      • 1.5、原主节点后续处理
      • 1.6、注意点
    • 2、节点运维
      • 2.1、节点下线
      • 2.2、节点上线
      • 2.3、节点配置
    • 3、 高可用读写分离
      • 3.1、从节点的作用
      • 3.2、Redis Sentinel读写分离设计思路

1、故障转移日志分析

1.1、Redis Sentinel拓扑结构

本次故障转移的分析直接使用的拓扑和配置进行说明，为了方便分析故障转移的过程，表9-4列出了每个节点的角色、ip、端口、进程号、runId。


因为故障转移涉及节点关系的变化，所以下面说明中用端口号代表节点。

1.2、开始故障转移测试

模拟故障的方法有很多，比较典型的方法有以下几种：

  • 方法一，强制杀掉对应节点的进程号，这样可以模拟出宕机的效果。
  • 方法二，使用Redis的debug sleep命令，让节点进入睡眠状态，这样可以模拟阻塞的效果。
  • 方法三，使用Redis的shutdown命令，模拟正常的停掉Redis。

本次我们使用方法一进行测试，因为从实际经验来看，数百上千台机器偶尔宕机一两台是会不定期出现的，为了方便分析日志行为，这里记录一下操作的时间和命令。

用kill-9使主节点的进程宕机，操作时间2016-07-2409：40：35：

$kill-919661

1.3、观察效果

6380节点晋升为主节点，6381节点成为6380节点的从节点。

1.4、故障转移分析

相信故障转移的效果和预想的一样，这里重点分析相应节点的日志。

(1)6379节点日志

两个复制请求，分别来自端口为6380和6381的从节点：

19661:M24Jul 09:22:16.907 * Slave127.0.0.1:6380 asksforsynchronization19661:M24Jul 09:22:16.907 * Full resync requested by slave127.0.0.1:6380 …19661:M24Jul 09:22:16.919 * Synchronization with slave127.0.0.1:6380 succeeded19661:M24Jul 09:22:23.396 * Slave127.0.0.1:6381 asksforsynchronization19661:M24Jul 09:22:23.396 * Full resync requested by slave127.0.0.1:6381 …19661:M24Jul 09:22:23.432 * Synchronization with slave127.0.0.1:6381 succeeded

09：40：35做了kill-9操作，由于模拟的是宕机效果，所以6379节点没有看到任何日志（这点和shutdown操作不太相同）​。

(2)6380节点日志

6380节点在09：40：35之后发现它与6379节点已经失联：

19667:S24Jul 09:40:35.788# Connection with master lost.19667:S24Jul 09:40:35.788 * Caching the disconnected master state.19667:S24Jul 09:40:35.974 * Connecting to MASTER127.0.0.1:637919667:S24Jul 09:40:35.974 * MASTER<->SLAVEsyncstarted19667:S24Jul 09:40:35.975# Error condition on socket for SYNC: Connectionrefused …

09：41：06时它接到Sentinel节点的命令：清理原来缓存的主节点状态，Sentinel节点将6380节点晋升为主节点，并重写配置：

19667:M24Jul 09:41:06.161 * Discarding previously cached master state.19667:M24Jul 09:41:06.161 * MASTER MODE enabled(user request from'id=7 addr=127.0.0.1:46759 fd=10 name=sentinel-7044753f-cmd age=1111 idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=0 qbuf-free=32768 obl=36 oll=0 omem=0 events=rw cmd=exec')19667:M24Jul 09:41:06.161# CONFIG REWRITE executed with success.

6381节点发来了复制请求：

19667:M24Jul 09:41:07.499 * Slave127.0.0.1:6381 asksforsynchronization19667:M24Jul 09:41:07.499 * Full resync requested by slave127.0.0.1:6381 …19667:M24Jul 09:41:07.548 * Background saving terminated with success19667:M24Jul 09:41:07.548 * Synchronization with slave127.0.0.1:6381 succeeded

(3)6381节点日志

6381节点同样与6379节点失联：

19685:S24Jul 09:40:35.788# Connection with master lost.19685:S24Jul 09:40:35.788 * Caching the disconnected master state.19685:S24Jul 09:40:36.425 * Connecting to MASTER127.0.0.1:637919685:S24Jul 09:40:36.425 * MASTER<->SLAVEsyncstarted19685:S24Jul 09:40:36.425# Error condition on socket for SYNC: Connection refused…

后续操作如下：

1)09：41：06时它接到Sentinel节点的命令，清理原来缓存的主节点状态，让它去复制新的主节点（6380节点）​：

19685:S24Jul 09:41:06.497# Error condition on socket for SYNC: Connection refused19685:S24Jul 09:41:07.008 * Discarding previously cached master state.19685:S24Jul 09:41:07.008 * SLAVE OF127.0.0.1:6380 enabled(user request from'id=7 addr=127.0.0.1:55872 fd=10 name=sentinel-7044753f-cmd age=1111 idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=133 qbuf-free=32635 obl=36 oll=0 omem=0 events=rw cmd=exec')19685:S24Jul 09:41:07.008# CONFIG REWRITE executed with success.

2)向新的主节点（6380节点）发起复制操作：

19685:S24Jul 09:41:07.498 * Connecting to MASTER127.0.0.1:6380 …19685:S24Jul 09:41:07.549 * MASTER<->SLAVE sync: Finished with success

(4)sentinel-1节点日志

09：41：05对6379节点作了主观下线(+sdown)，注意这个时间正好是kill-9后的30秒，和down-after-milliseconds的配置是一致的。Sentinel节点更新自己的配置纪元(new-epoch)：

19697:X24Jul 09:41:05.850# +sdown master mymaster 127.0.0.1 637919697:X24Jul 09:41:05.928# +new-epoch 1

后续操作如下：

1)投票给sentinel-3节点：

19697:X24Jul 09:41:05.929# +vote-for-leader 7044753f564e42b1578341acf4c49dca3681151c119697:X24Jul 09:41:06.913# +odown master mymaster 127.0.0.1 6379 #quorum 3/2

2)更新状态：从sentinel-3节点（领导者）得知：故障转移后6380节点变为主节点，并发现了两个从节点6381和6379，并在30秒后对(09：41：07~09：41：37)6379节点做了主观下线：

19697:X24Jul 09:41:06.913# Next failover delay: I will not start a failoverbefore Sun Jul2409:47:06201619697:X24Jul 09:41:07.008# +config-update-from sentinel 127.0.0.1:26381127.0.0.126381@ mymaster127.0.0.1637919697:X24Jul 09:41:07.008# +switch-master mymaster 127.0.0.1 6379 127.0.0.1 638019697:X24Jul 09:41:07.008 * +slave slave127.0.0.1:6381127.0.0.16381@ mymaster127.0.0.1638019697:X24Jul 09:41:07.008 * +slave slave127.0.0.1:6379127.0.0.16379@ mymaster127.0.0.1638019697:X24Jul 09:41:37.060# +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @mymaster127.0.0.16380

(5)sentinel-2节点日志

整个过程和sentinel-1节点是一样的，这里就不占用篇幅分析了。

(6)sentinel-3节点日志

从sentinel-1节点和sentinel-2节点的日志来看，sentinel-3节点是领导者，所以分析sentinel-3节点的日志至关重要。

后续操作如下。

1)达到了客观下线的条件：

19713:X24Jul 09:41:05.854# +sdown master mymaster 127.0.0.1 637919713:X24Jul 09:41:05.909# +odown master mymaster 127.0.0.1 6379 #quorum 2/219713:X24Jul 09:41:05.909# +new-epoch 1

2)sentinel-3节点被选为领导者：

19713:X24Jul 09:41:05.909# +try-failover master mymaster 127.0.0.1 637919713:X24Jul 09:41:05.911# +vote-for-leader 7044753f564e42b1578341acf4c49dca3681151c119713:X24Jul 09:41:05.929# 127.0.0.1:26379 voted for 7044753f564e42b1578341acf4c49dca3681151c119713:X24Jul 09:41:05.930# 127.0.0.1:26380 voted for 7044753f564e42b1578341acf4c49dca3681151c119713:X24Jul 09:41:06.001# +elected-leader master mymaster 127.0.0.1 6379

下表展示了3个Sentinel节点完成客观下线的时间点，从时间点可以看到sentinel-3节点最先完成客观下线。

3)故障转移。每一步都可以通过发布订阅来获取，对于每个字段的说明可以参考下表。

寻找合适的从节点作为新的主节点：

19713:X24Jul 09:41:06.001# +failover-state-select-slave master mymaster127.0.0.16379

选出了合适的从节点（6380节点）​：

19713:X24Jul 09:41:06.077# +selected-slave slave 127.0.0.1:6380 127.0.0.16380@ mymaster127.0.0.16379

命令6380节点执行slaveof no one，使其成为主节点：

19713:X24Jul 09:41:06.077 * +failover-state-send-slaveof-noone slave127.0.0.1:6380127.0.0.16380@ mymaster127.0.0.16379

等待6380节点晋升为主节点：

19713:X24Jul 09:41:06.161 * +failover-state-wait-promotion slave127.0.0.1:6380127.0.0.16380@ mymaster127.0.0.16379

确认6380节点已经晋升为主节点：

19713:X24Jul 09:41:06.927# +promoted-slave slave 127.0.0.1:6380 127.0.0.16380@ mymaster127.0.0.16379

故障转移进入重新配置从节点阶段：

19713:X24Jul 09:41:06.927# +failover-state-reconf-slaves master mymaster127.0.0.16379

命令6381节点复制新的主节点：

19713:X24Jul 09:41:07.008 * +slave-reconf-sent slave127.0.0.1:6381127.0.0.16381@ mymaster127.0.0.16379

6381节点正在重新配置成为6380节点的从节点，但是同步过程尚未完成：

19713:X24Jul 09:41:07.955 * +slave-reconf-inprog slave127.0.0.1:6381127.0.0.16381@ mymaster127.0.0.16379

6381节点完成对6380节点的同步：

19713:X24Jul 09:41:07.955 * +slave-reconf-done slave127.0.0.1:6381127.0.0.16381@ mymaster127.0.0.16379

故障转移顺利完成：

19713:X24Jul 09:41:08.045# +failover-end master mymaster 127.0.0.1 6379

故障转移成功后，发布主节点的切换消息：

19713:X24Jul 09:41:08.045# +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380

下表记录了Redis Sentinel在故障转移一些重要的事件消息对应的频道。

<instance details>格式如下：

<instance-type><name><ip><port>@<master-name><master-ip><master-port>

1.5、原主节点后续处理

重新启动原来的6379节点：

redis-server redis-6379.conf操作时间:2016-07-24 09:46:21

(1)6379节点

启动后接到Sentinel节点的命令，让它去复制6380节点：

22223:M24Jul 09:46:21.260 * The server is now ready to accept connections on port637922223:S24Jul 09:46:31.323 * SLAVE OF127.0.0.1:6380 enabled(user request from'id=2 addr=127.0.0.1:51187 fd=6 name=sentinel-94dde2f5-cmd age=10 idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=0 qbuf-free=32768 obl=36 oll=0 omem=0 events=rw cmd=exec')22223:S24Jul 09:46:31.323# CONFIG REWRITE executed with success.…

(2)6380节点

接到6379节点的复制请求，做复制的相应处理：

19667:M24Jul 09:46:32.284 * Slave127.0.0.1:6379 asksforsynchronization19667:M24Jul 09:46:32.284 * Full resync requested by slave127.0.0.1:6379 …19667:M24Jul 09:46:32.353 * Synchronization with slave127.0.0.1:6379 succeeded

(3)sentinel-1节点日志

撤销对6379节点主观下线的决定：

19707:X24Jul 09:46:21.406# -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @mymaster127.0.0.16380

(4)sentinel-2节点日志

撤销对6379节点主观下线的决定：

19713:X24Jul 09:46:21.408# -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @mymaster127.0.0.16380

(5)sentinel-3节点日志

撤销对6379节点主观下线的决定，更新Sentinel节点配置：

19697:X24Jul 09:46:21.367# -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @mymaster127.0.0.1638019697:X24Jul 09:46:31.322 * +convert-to-slave slave127.0.0.1:6379127.0.0.16379@ mymaster127.0.0.16380

1.6、注意点

部署各个节点的机器时间尽量要同步，否则日志的时序性会混乱，例如可以给机器添加NTP服务来同步时间。

2、节点运维

2.1、节点下线

在介绍如何进行节点下线之前，首先需要弄清两个概念：临时下线和永久下线。

  • 临时下线：暂时将节点关掉，之后还会重新启动，继续提供服务。
  • 永久下线：将节点关掉后不再使用，需要做一些清理工作，如删除配置文件、持久化文件、日志文件。

所以运维人员需要弄清楚本次下线操作是临时下线还是永久下线。

通常来看，无论是主节点、从节点还是Sentinel节点，下线原因无外乎以下几种：

  • 节点所在的机器出现了不稳定或者即将过保被回收。
  • 节点所在的机器性能比较差或者内存比较小，无法支撑应用方的需求。
  • 节点自身出现服务不正常情况，需要快速处理。

(1)主节点

如果需要对主节点进行下线，比较合理的做法是选出一个“合适”​（例如性能更高的机器）的从节点，使用sentinel failover功能将从节点晋升主节点，只需要在任意可用的Sentinel节点执行如下操作即可。

sentinel failover<master name>

如图所示，在任意一个Sentinel节点上（例如 26379端口节点）执行sentinel failover即可。

Redis Sentinel存在多个从节点时，如果想将指定从节点晋升为主节点，可以将其他从节点的slavepriority配置为0，但是需要注意failover后，将slave-priority调回原值。

(2)从节点和Sentinel节点

如果需要对从节点或者Sentinel节点进行下线，只需要确定好是临时还是永久下线后执行相应操作即可。如果使用了读写分离，下线从节点需要保证应用方可以感知从节点的下线变化，从而把读取请求路由到其他节点。

需要注意的是，Sentinel节点依然会对这些下线节点进行定期监控，这是由Redis Sentinel的设计思路所决定的。下面日志显示（需要设置loglevel=debug）​，6380节点下线后，Sentinel节点还是会定期对其监控，会造成一定的网络资源浪费。

-cmd-link slave127.0.0.1:6380127.0.0.16380@ mymaster127.0.0.16379#Connection refused-pubsub-link slave127.0.0.1:6380127.0.0.16380@ mymaster127.0.0.16379#Connection refused…

2.2、节点上线

(1)添加从节点

添加从节点的场景大致有如下几种：

  • 使用了读写分离，但现有的从节点无法支撑应用方的流量。
  • 主节点没有可用的从节点，无法支持故障转移。
  • 添加一个更强悍的从节点利用手动failover替换主节点。

添加方法：添加slaveof{masterIp}{masterPort}的配置，使用redis-server启动即可，它将被Sentinel节点自动发现。

(2)添加Sentinel节点

添加Sentinel节点的场景可以分为以下几种：

  • 当前Sentinel节点数量不够，无法达到Redis Sentinel健壮性要求或者无法达到票数。
  • 原Sentinel节点所在机器需要下线。

添加方法：添加sentinel monitor主节点的配置，使用redis-sentinel启动即可，它将被其余Sentinel节点自动发现。

(3)添加主节点

因为Redis Sentinel中只能有一个主节点，所以不需要添加主节点，如果需要替换主节点，可以使用Sentinelfailover手动故障转移。

2.3、节点配置

这里给出Sentinel节点配置时要注意的地方：

  • Sentinel节点配置尽可能一致，这样在判断节点故障时会更加准确。
  • Sentinel节点支持的命令非常有限，例如config命令是不支持的，而Sentinel节点也需要dir、loglevel之类的配置，所以尽量在一开始规划好，不过所幸Sentinel节点不存储数据，如果需要修改配置，重新启动即可。

Sentinel节点只支持如下命令：ping、sentinel、subscribe、unsubscribe、psubscribe punsubscribe、publish、info、role、client、shutdown。

3、 高可用读写分离

3.1、从节点的作用

从节点一般可以起到两个作用：第一，当主节点出现故障时，作为主节点的后备“顶”上来实现故障转移，RedisSentinel已经实现了该功能的自动化，实现了真正的高可用。第二，扩展主节点的读能力，尤其是在读多写少的场景非常适用，通常的模型如图所示。


但上述模型中，从节点不是高可用的，如果slave-1节点出现故障，首先客户端client-1将与其失联，其次Sentinel节点只会对该节点做主观下线，因为RedisSentinel的故障转移是针对主节点的。所以很多时候，Redis Sentinel中的从节点仅仅是作为主节点一个热备，不让它参与客户端的读操作，就是为了保证整体高可用性，但实际上这种使用方法还是有一些浪费，尤其是在有很多从节点或者确实需要读写分离的场景，所以如何实现从节点的高可用是非常有必要的。

3.2、Redis Sentinel读写分离设计思路

Redis Sentinel在对各个节点的监控中，如果有对应事件的发生，都会发出相应的事件消息​，其中和从节点变动的事件有以下几个：

  • +switch-master：切换主节点（原来的从节点晋升为主节点）​，说明减少了某个从节点。
  • +convert-to-slave：切换从节点（原来的主节点降级为从节点）​，说明添加了某个从节点。
  • +sdown：主观下线，说明可能某个从节点可能不可用（因为对从节点不会做客观下线）​，所以在实现客户端时可以采用自身策略来实现类似主观下线的功能。
  • +reboot：重新启动了某个节点，如果它的角色是slave，那么说明添加了某个从节点。

所以在设计Redis Sentinel的从节点高可用时，只要能够实时掌握所有从节点的状态，把所有从节点看做一个资源池（如图所示）​，无论是上线还是下线从节点，客户端都能及时感知到（将其从资源池中添加或者删除）​，这样从节点的高可用目标就达到了。

http://www.jsqmd.com/news/1203482/

相关文章：

  • 2026年废高压电缆回收指南：聚焦源头厂家河北豪雄 - 品牌鉴赏官2026
  • 2026果筐机选购指南 多家正规厂家实地体验评测汇总 - 奔跑123
  • 2026年7月最新唐山格拉苏蒂官方售后热线及客户服务网点地址 - 亨得利钟表维修中心
  • 百达翡丽中国官方售后服务中心｜地址及官方客服热线权威信息通告（2026年7月更新） - 百达翡丽服务中心
  • 欧米茄中国官方售后服务中心｜地址与官方客服热线权威信息通告（2026年7月最新） - 欧米茄服务中心
  • 格拉苏蒂中国官方售后服务中心｜服务热线及全部官方地址权威信息通告（2026年7月最新） - 亨得利钟表维修中心
  • Codeforces Round 1108 (Div. 2)
  • WMI Provider Host高CPU占用诊断与优化指南
  • 2026 年现阶段怒江比较好的滑动钢制闸门定做厂家哪家好,别再用传统闸门了：它如何颠覆你的操作效率？ - 行业严选官
  • 解决应用商店安装后桌面图标不显示的完整方案
  • 亲身探访广州芝柏官方售后服务中心｜全新热线和维修门店地址（2026年7月最新） - 亨得利官方服务中心
  • 2026潍坊家居采暖升级 靠谱采暖炉售卖店梳理推荐 - 奔跑123
  • 泰格豪雅中国官方售后服务中心｜服务热线及门店地址权威信息声明（2026年7月最新） - 亨得利官方服务中心
  • 2026年浙江企业报税服务选择指南与可靠联系方式解析 - 品牌鉴赏官2026
  • 劳力士中国官方售后服务中心地址与维修热线实地考察报告+多信源验证（2026年7月最新） - 劳力士官方服务中心
  • 浪琴官方售后服务中心电话及详细网点地址实地考察报告_多信源验证(2026年7月更新) - 浪琴服务中心
  • 深圳夏令营哪家师资强：军博营地师资雄厚 - 松梢月冷
  • 2026精选评测：济南空调移机机构如何选？顺达制冷空调精工维修解析 - 品牌鉴赏官2026
  • 2026年网架厂家推荐排行榜：煤棚网架/干煤棚网架/球形网架/体育馆网架/大跨度网架/螺栓球网架/钢结构网架源头厂家实力深度解析 - 企业推荐官【官方】
  • 2026年 内江五金建材榜单：劳保用品/水电材料/综合五金一站式采购与厂家实力推荐 - 甄选服务推荐
  • 2026 年更新：中山可靠的三轴自动卷锥机订做厂家深度解析,别再手动卷锥了！这台机器如何让你效率翻倍 - 品质体验官
  • 什么是谷歌SEO？从0到1带你拆解价值百万的独立站流量密码！
  • 2026天津危化品存储柜售后优良厂家排行参考榜单 - 奔跑123
  • 百达翡丽保养油售后保养维修步骤详解权威公示（2026年7月最新） - 百达翡丽官方售后中心
  • 2026年 工业照明灯/台湾天得三色灯/警示灯/指示灯厂商：精准信号与高亮耐用的标杆之选 - 企业推荐官【官方】
  • 2026年7月亲身到店体验厦门亨得利官方名表服务中心｜完整地址及售后热线 - 亨得利官方
  • 深圳夏令营国防教育类推荐：军博营地官方权威 - 松梢月冷
  • 2026年上海环氧地坪厂家推荐排行参考汇总 - 奔跑123
  • 鸿蒙APP如何复用已有小程序资产，将微信小程序运行在原生鸿蒙系统
  • 2026 年至今，清涧知名的草坪种植基地批发厂家怎么联系,别再租草坪了！秘密揭秘高效种植基地的惊人秘密 - 领域鉴赏官