既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上C C++开发知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
可以看出slave重新加入到了主从复制中
-sdown: 说明是恢复服务
现在将Master 强制杀掉
哨兵控制台打印
我们进入 6381 查看状态
6381 已经是 master了 并且拥有一个 6380的slave
重新启动6379
6379已经恢复,并且将6379设置为6380的slave
这时我们查看sentinel.conf 发现 我们刚刚配置的端口已经变成6381
而6381也有2个slave
查看etc下面的redis.6379.conf 和 redis.6380.conf 发现哨兵(sentinel) 已经对该文件做了修改
6379之前是没有配置,所以就添加到了最后一行
sentinel后台运行和redis的配置文件一样修改daemonize参数
多个哨兵(sentinel)
配置了一个哨兵,如果该哨兵宕机了,那么整个主从架构就回复到了原始的情况,所以我们可以配置多个哨兵,每个哨兵监控Redis信息,并且哨兵之间也会互相监控
修改sentinel.conf中的最低通过票数
在拷贝二份sentinel.conf
cp ./sentinel.conf sentinel.26479.conf
cp ./sentinel.conf sentinel.26579.conf
修改sentinel.26579.conf和sentinel.26479.conf中的port
在新开二个xshell会话,查看26479 和 26579的控制台信息
在每个会话分别启动一个sentinel
此时控制台信息
26379:
增加了2个sentinel
26479:
26579:
强制杀掉6379
Sentinel发现宕机情况
3个都是一样的
重新启动6379,sentinel 打印的信息室一样的
好吧多个sentinel和一个sentinel的效果是一样,那么我们杀掉master试试
和单个哨兵是差不多的
整个故障转移过程是需要啊一个leader来调整的,所以多个sentinel会选举一个leader
在Leader触发failover之前,首先wait数秒(随即0~5),以便让其他sentinel实例准备和调整, 如果一切正常,那么leader就需要开始将一个salve提升为master,此slave必须为状态良好(不能处于SDOWN/ODOWN状态)且权重值最低(redis.conf中)的,当master身份被确认后,开始failover
另外2个sentinel的控制台信息
26479:
26579:
大概结果就是这样 ╮(╯▽╰)╭
那么我们强行杀掉一个sentinel试试
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上C C++开发知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
0209801)]
[外链图片转存中…(img-o1Mc3U0c-1715530209801)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上C C++开发知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新