千家信息网

Redis哨兵部署(sentinel)(实验)

发表于:2026-11-02 作者:千家信息网编辑
千家信息网最后更新 2026年11月02日,首先感谢"吧喱公路"的引导,打开了我对哨兵的理解思路,再次谢谢。Redis的哨兵(sentinel)哨兵适用于非集群结构的redis环境,比如:redis主从环境。关于哨兵集群,我这里就不做实验了,网
千家信息网最后更新 2026年11月02日Redis哨兵部署(sentinel)(实验)


首先感谢"吧喱公路"的引导,打开了我对哨兵的理解思路,再次谢谢。


Redis的哨兵(sentinel)

哨兵适用于非集群结构的redis环境,比如:redis主从环境。


关于哨兵集群,我这里就不做实验了,网上有大量的配置方法。

哨兵集群的核心思想,就是解决哨兵的单点故障问题。

个人认为,有做哨兵集群的经费,不如直接做个redis集群了。


环境描述:(主从从结构)

master:192.168.2.100:6379 #单节点sentinel运行在这个环境上

slave:192.168.2.200:6379

savle:192.168.2.201:6379

redis安装路径:/usr/local/redis-3.0.6-6379


redis.conf关键配置:(这里不絮诉基本配置了,主从配置参考:https://blog.51cto.com/13690439/2118890)

master:

# vim redis.conf

requirepass "123456" //设置连接master密码

masterauth "123456" //登录master时,调用该参数

slave:

# vim etc/redis.conf

slaveof 192.168.2.100 6379 //指定主库IP和端口

requirepass "123456" //之所以3个redis都这样写,是为了故障切换后,info replication显示slave0信息

masterauth 123456 //登录master时,调用该参数

哨兵关键配置:(sentinel.conf)

# vim sentinel.conf

port 26379 //端口

sentinel monitor mymaster 192.168.2.100 6379 1

//master-name可以自定义、监听IP:port 几个sentinel认为故障时,才算真正的故障

sentinel down-after-milliseconds mymaster 3000

//哨兵发送PING消息,等待PONG消息的时间,超过设定时间表示故障;毫秒

sentinel failover-timeout mymaster 10000

//故障转移(failover)超时时间,超过设定时间表示故障转移失败;毫秒

sentinel auth-pass mymaster 123456 //设置连接master需要的密码

启动master的redis:

# redis-server redis.conf

启动哨兵:(新开一个xshell)

# redis-sentinel sentinel.conf


启动slave的redis:

# redis-server redis.conf

哨兵的输出:

# Sentinel runid is e49df1197325687d9a40508c00f466a8c6e596db

//哨兵ID

# +monitor master mymaster 192.168.2.100 6379 quorum 1

//+monitor:增加了一个master监控,后面就是master的信息

* +slave slave 192.168.2.200:6379 192.168.2.200 6379 @ mymaster 192.168.2.100 6379

//+salve:增加了一个salve监控,后面是salve的信息

* +slave slave 192.168.2.201:6379 192.168.2.201 6379 @ mymaster 192.168.2.100 6379

//+salve:增加了一个salve监控,后面是salve的信息

master上登录redis:

# redis-cli -h 192.168.2.100 -p 6379 -a 123456

192.168.2.100:6379> set name zhangsan

OK

192.168.2.100:6379> set age 26

OK

192.168.2.100:6379> set home beijing

OK

192.168.2.100:6379> keys *

1) "name"

2) "home"

3) "age"


salve上登录redis:(两个salve登录查看,数据同步正常)

# redis-cli -h 192.168.2.200 -p 6379 -a 123456

192.168.2.200:6379> keys *

1) "name"

2) "home"

3) "age"

停止master的redis:(注意观察哨兵的输出)

# ps -ef |grep redis

root 11467 1 0 17:12 ? 00:00:00 redis-server *:6379

root 11473 4650 0 17:12 pts/1 00:00:00 redis-sentinel *:26379 [sentinel]

root 11513 4339 0 17:16 pts/0 00:00:00 grep --color=auto redis

# kill 11467

哨兵的输出:

# +sdown master mymaster 192.168.2.100 6379

//+sdown:master节点挂了。后面是master信息

# +odown master mymaster 192.168.2.100 6379 #quorum 1/1

# +new-epoch 14

# +try-failover master mymaster 192.168.2.100 6379

//开始恢复故障

# +vote-for-leader e49df1197325687d9a40508c00f466a8c6e596db 14

//投票选举节点的哨兵信息,因为我们就一个哨兵,所以就是自己 leader

# +elected-leader master mymaster 192.168.2.100 6379

//选举节点后替换谁

# +failover-state-select-slave master mymaster 192.168.2.100 6379

//开始为故障的master选举

# +selected-slave slave 192.168.2.200:6379 192.168.2.200 6379 @ mymaster 192.168.2.100 6379

//节点选举结果,选中192.168.2.200:6379来替换master

* +failover-state-send-slaveof-noone slave 192.168.2.200:6379 192.168.2.200 6379 @ mymaster 192.168.2.100 6379

//确认节点选举结果

* +failover-state-wait-promotion slave 192.168.2.200:6379 192.168.2.200 6379 @ mymaster 192.168.2.100 6379

//选中的节点正在升级为master

# +promoted-slave slave 192.168.2.200:6379 192.168.2.200 6379 @ mymaster 192.168.2.100 6379

//选中的节点已成功升级为master

# +failover-state-reconf-slaves master mymaster 192.168.2.100 6379

//切换故障master的状态

* +slave-reconf-sent slave 192.168.2.201:6379 192.168.2.201 6379 @ mymaster 192.168.2.100 6379

//

* +slave-reconf-inprog slave 192.168.2.201:6379 192.168.2.201 6379 @ mymaster 192.168.2.100 6379

//其他节点同步故障master信息

* +slave-reconf-done slave 192.168.2.201:6379 192.168.2.201 6379 @ mymaster 192.168.2.100 6379

//其他节点完成故障master的同步

# +failover-end master mymaster 192.168.2.100 6379

//故障恢复完成

# +switch-master mymaster 192.168.2.100 6379 192.168.2.200 6379

//master从192.168.2.100:6379 变为 192.168.2.200:6379

* +slave slave 192.168.2.201:6379 192.168.2.201 6379 @ mymaster 192.168.2.200 6379

//其他节点指定新的master

* +slave slave 192.168.2.100:6379 192.168.2.100 6379 @ mymaster 192.168.2.200 6379

//故障master指定新的master

# +sdown slave 192.168.2.100:6379 192.168.2.100 6379 @ mymaster 192.168.2.200 6379

//192.168.2.100:6379宕机,待恢复


启动master的redis(注意观察哨兵的输出)

# redis-server redis.conf

哨兵的输出:

# -sdown slave 192.168.2.100:6379 192.168.2.100 6379 @ mymaster 192.168.2.200 6379

//故障master节点已经恢复

* +convert-to-slave slave 192.168.2.100:6379 192.168.2.100 6379 @ mymaster 192.168.2.200 6379

//故障master节点变为salve,他的master为192.168.2.200:6379


现在我们查看主从的状态:

192.168.2.100上查看:

# redis-cli -h 192.168.2.100 -p 6379 -a 123456

192.168.2.100:6379> info replication

# Replication

role:slave

master_host:192.168.2.200

master_port:6379

master_link_status:up

192.168.2.100:6379> set ab 123

(error) READONLY You can't write against a read only slave.

192.168.2.100:6379> get name

"zhagnsan"

192.168.2.201上查看:

# redis-cli -h 192.168.2.201 -p 6379 -a 123456

192.168.2.201:6379> info replication

# Replication

role:slave

master_host:192.168.2.200

master_port:6379

master_link_status:up

192.168.2.201:6379> set ab 123

(error) READONLY You can't write against a read only slave.

192.168.2.201:6379> get name

"zhagnsan"

192.168.2.200上查看:

# redis-cli -h 192.168.2.200 -p 6379 -a 123456

192.168.2.200:6379> info replication

# Replication

role:master

connected_slaves:2

slave0:ip=192.168.2.201,port=6379,state=online,offset=24990,lag=1

slave1:ip=192.168.2.100,port=6379,state=online,offset=24990,lag=0

192.168.2.200:6379> set ab 123

OK

192.168.2.200:6379> keys *

1) "name"

2) "home"

3) "age"

4) "ab"

总结:通过哨兵(sentinel)实现了主从从环境高可用效果。

master在宕机后,通过哨兵自动将其中一个salve提升为master,切换过程中,数据保存完整。

但我们也发现,原master不能继续插入key了, 而客户端连接还是会连原master,

这时,我们就需要在数据库连接池做一些规则设置了。

由于目前我能力有限,无法解释连接池问题,还请见谅。


哨兵 故障 节点 信息 主从 环境 集群 登录 输出 选举 配置 时间 就是 数据 切换 同步 监控 关键 参数 密码 数据库的安全要保护哪些东西 数据库安全各自的含义是什么 生产安全数据库录入 数据库的安全性及管理 数据库安全策略包含哪些 海淀数据库安全审计系统 建立农村房屋安全信息数据库 易用的数据库客户端支持安全管理 连接数据库失败ssl安全错误 数据库的锁怎样保障安全 瑰夏咖啡 互联网科技海报 A股互联网金融科技公司 互联网与科技发展 港股互联网科技股 互联网科技股票 碳银互联网科技有限公司 深圳期待互联网科技 互联网科技股午盘股票涨跌 山东吉时兔互联网科技有限公司 北京华百购互联网科技有限公司 互联网5g黑科技有哪些 互联网科技的全部知识 朱啸虎曾投资哪些互联网科技企业 互联网金融科技元年 黑科技 体验场景 互联网大会 南京一网一红互联网科技有限公司 互联网领先科技成果宣传视频 互联网大会出现的黑科技 科技美学互联网 艺术 华服互联网科技靠谱吗 美国互联网科技巨头监管 互联网科技公司官网 火传媒上海互联网科技 字节跳动和互联网科技 重庆互联网医院沙龙医盟信息科技 未来五年的互联网科技 半导体行业属于互联网高科技类吗 现代科技的标志之一的互联网 武汉亿视互联网科技有限公司
0