十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
这篇文章主要介绍“redis Sentinel哨兵模式的原理及配置”,在日常操作中,相信很多人在Redis Sentinel哨兵模式的原理及配置问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”Redis Sentinel哨兵模式的原理及配置”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
10年积累的网站设计、做网站经验,可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你,你也不认识我。但先网站设计后付款的网站建设流程,更有宁强免费网站建设让你可以放心的选择与我们合作。
一.安装配置
在1个master 1个slave 的环境中加一个sentinel,
进入redis源码安装目录copy sentinel.conf文件
# cd /u01/packages/redis-3.0.6
# cp sentinel.conf /usr/local/redis/etc/
# vi /usr/local/redis/etc/sentinel.conf
daemonize yes
sentinel monitor mymaster 127.0.0.1 6379 1
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
参数解释:
sentinel monitor mymaster 127.0.0.1 6379 1
指示 Sentinel 去监视一个被命名为 mymaster 的master,可指定为任何名字
Master IP为127.0.0.1 , 端口号为 6379 ,
这个master判断为失效至少需要 1 个 Sentinel 同意 (只要同意 Sentinel 的数量不达标,自动故障迁移就不会执行)
注意,无论你设置多少个 Sentinel 同意才能判断一个服务器失效, 一个 Sentinel 都需要获得系统中多数(majority) Sentinel 的支持, 才能发起一次自动故障迁移
sentinel down-after-milliseconds mymaster 30000
down-after-milliseconds 指定了 Sentinel 认为master已经断线所需的毫秒数
sentinel parallel-syncs mymaster 1
parallel-syncs 指定了在执行故障转移时, 最多可以有多少个slave同时对新的master进行同步, 这个数字越小, 完成故障转移所需的时间就越长
sentinel failover-timeout mymaster 180000
failover-timeout 指定故障切换允许的毫秒数,超过这个时间,就认为故障切换失败,默认为3分钟
启动sentinel
# redis-sentinel /usr/local/redis/etc/sentinel.conf
查看状态
# redis-cli -p 26379
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=1,sentinels=1
至此,配置sentinel工作完成
Sentinel 相关命令
• INFO sentinel的基本状态信息
• PING :返回 PONG
• SENTINEL masters :列出所有被监视的master,以及这些master的当前状态
• SENTINEL slaves
• SENTINEL get-master-addr-by-name
• SENTINEL reset
• SENTINEL failover
二. 原理:
故障转移时主要是解决两个问题,一是选Leader Sentinel,二是选新的master
1.选Leader Sentinel规则
Sentinel 自动故障迁移使用 Raft 算法来选举领头(Leader)Sentinel , 从而确保在一个给定的纪元时期(epoch)里, 只有一个Leader产生。
表示在同一个时期, 不会有两个 Sentinel 同时被选中为Leader, 并且各个 Sentinel 在同一个时期中只会对一个Leader进行投票。
注:Raft算法主要思想是同一期Term(Epoch)投票中少数服从多数原则达成一致,选出Leader
具体算法这里不过多解释,详细可参考文章:
https://www.jianshu.com/p/8e4bbe7e276c
2.选新master规则
1> 在失效主服务器属下的从服务器当中, 那些被标记为主观下线、已断线、或者最后一次回复 PING 命令的时间大于五秒钟的从服务器都会被淘汰。
2> 在失效主服务器属下的从服务器当中, 那些与失效主服务器连接断开的时长超过 down-after 选项指定的时长十倍的从服务器都会被淘汰。
3> 在经历了以上两轮淘汰之后剩下来的从服务器中, 我们选出复制偏移量(replication offset)最大的那个slave作为新的master服务器; 如果复制偏移量不可用, 或者slave服务器的复制偏移量相同, 那么带有最小运行 ID 的那个从服务器成为新的master。
一次故障转移步骤:
1>发现master已进入客观下线状态。
2>对当前纪元时期(epoch)进行自增, 并尝试在这个纪元时期中当选。
3>如果当选失败, 那么在设定的故障迁移超时时间的两倍之后, 重新尝试当选。 如果当选成功, 那么执行以下步骤
4>选出一个slave,并将它升级为master。
5>向被选中的slave发送 SLAVEOF NO ONE 命令,让它转变为master。
通过发布与订阅功能, 将更新后的配置传播给所有其他 Sentinel , 其他 Sentinel 对它们自己的配置进行更新。
6>向已下线master的其它slave发送 SLAVEOF host port 命令, 让它们去复制新的master。
7>当所有slave都已经开始复制新的master时, 领头 Sentinel 终止这次故障迁移操作。
到此,关于“Redis Sentinel哨兵模式的原理及配置”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注创新互联网站,小编会继续努力为大家带来更多实用的文章!