<div id="navCategory"></div> 讯享网
哨兵的核心功能：在主从复制的基础上，哨兵引入了主节点的自动故障转移
哨兵：是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的Master 并将所有Slave 连接到新的 Master。所以整个运行哨兵的集群的数量不得少于3个节点。
- 监控：哨兵会不断地检查主节点和从节点是否运作正常。
- 自动故障转移：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
- 通知提醒：哨兵可以将故障转移的结果发送给客户端
- 哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点就是特殊的redis节点，不存储数据
- 数据节点：主节点和从节点都是数据节点
注意：
哨兵的启动依赖于主从模式，所以须把主从模式安装好的情况下再去做哨兵模式，所有节点上都需要部署哨兵模式，哨兵模式会监控所有的Redis工作节点是否正常。
由哨兵节点定期监控主节点是否出现了故障，每个哨兵节点每隔1秒会向主节点、从节点及其它哨兵节点发送一次ping命令做一次心跳检测。 如果主节点在一定时间范围内不回复或者是回复一个错误消息，那么这个哨兵就会认为这个主节点主观下线了(单方面的），当超过半数哨兵节点认为该主节点下线了，这样就客观下线了。 此时哨兵节点会通过Raft算法〈选举算法）实现选举机制共同选举出一个哨兵节点为leader，来负责处理主节点的故障转移和通知。
故障转移过程如下：
● 将某一个从节点升级为新的主节点，让其它从节点指向新的主节点;
● 若原主节点恢复也变成从节点，并指向新的主节点;
● 通知客户端主节点已经更换。
主节点的选举条件：
- 过滤掉不健康的（已下线的），没有回复哨兵ping响应的从节点
- 选择配置文件中从节点优先级最高的（replication-priority,默认值为100）
- 选择复制偏移量最大的，也就是复制最完整的从节点。
1.关闭防火墙安全内核机制，所有节点全部执行
2.所有节点分别搭建网络yum源 ，需要联网
3.分别修改主机名
4.所有节点修改hosts文件
主从部署
1.所有节点安装redis
2.修改Master节点的配置文件
3.修改slave1和slave2两个从节点
4.验证主从效果
在Master节点上看日志
在master上动态查看日志：
在master上验证从节点
1.修改哨兵模式的配置文件（所有节点操作）
2.启动哨兵模式所有节点都要启动
#注意：先启主节点master，再启从节点slave
3.在master查看哨兵信息
所有节点都可以查看哨兵info sentinel
在Slave1上查看是否转换成功
在Slave2上查看是否转换成功
当原来的master修复后会做为slave从新加入
将权重值调成默认方便下次选举
总结 哨兵系统的搭建过程，有几点需要注意：
哨兵系统中的主从节点，与普通的主从节点并没有什么区别，故障发现和转移是由哨兵来控制和完成的。
哨兵节点本质上是Redis节点.
每个哨兵节点，只需要配置监控主节点，便可以自动发现其他的哨兵节点和从节点.
在哨兵节点启动和故障转移阶段，各个节点的配置文件会被重写（Config Rewrite）。
故障转移分三步
1.从下线的主服务的所有从服务里面挑选一个从服务， 将其转成主服务
2.已下线主服务的所有从服务改为复制新的主服务 挑选出新的主服务之后，领头sentinel 向原主服务的从服务发送 slaveof 新主服务 的命令，复制新master。
3.将已下线的主服务设置成新的主服务的从服务， 当其回复正常时，复制新的主服务，变成新的主服务的从服务 当已下线的服务重新上线时，sentinel会向其发送slaveof命令， 让其成为新主的从。
查看[root@master redis-5.0.9]下的master节点信息
查看[root@master redis-5.0.9]下的slaves节点信息
查看[root@master redis-5.0.9]下的哨兵节点信息
到此这篇关于redis搭建哨兵模式实现一主两从三哨兵的文章就介绍到这了,更多相关redis 一主两从三哨兵内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/167963.html